Scott's Weblog The weblog of an IT pro focusing on cloud computing, Kubernetes, Linux, containers, and networking

Technology Short Take 161

Welcome to Technology Short Take #161! It’s been a little over a month since the last Technology Short Take, although the Full Stack Journey recently did an “Audio Edition” of a Technology Short Take that you should probably check out. In any case, I’ve spent the last month collecting links to articles and tutorials from around the web on all the various technologies that us IT folk are likely to encounter in our day-to-day adventures. I hope there’s something here that you find useful!



  • Howard Oakley has a great series on Apple Silicon; the series is up to three posts so far. The first post provides a high-level overview of how Apple Silicon M-series chips are different, and the second post has more details on the capabilities of the P and E cores. The third post discusses how macOS allocates threads to different cores to maximize performance. Good stuff!
  • Looks like some significant bandwidth increases could be on the horizon; see this article for more details.


Cloud Computing/Cloud Management

Operating Systems/Applications



Career/Soft Skills

  • I love this idea!
  • Mike McQuaid talks about entitlement in open source. I think some of the lessons in this article could apply to a lot of different scenarios, not just open source usage.

That’s all for now! As always, thank you for taking the time to read this post, and feel free to reach out to me with any feedback or suggestions for improvement. You can reach me on Twitter, or find me in a number of different Slack communities (such as the Pulumi community Slack or the Kubernetes community Slack). I look forward to hearing from you!

Streamlining the User Experience for Accessing AKS Clusters

Lately I’ve been spending a little bit of time building Pulumi programs to assist with standing up Azure Kubernetes Service (AKS) clusters. I’ve learned a pretty fair amount about Azure and AKS along the way, as expected, but I was taken aback by the poor user experience (in my opinion) when it came to accessing the AKS clusters once they’d been established. In this post, I’ll share a small tweak you can make that will, in most cases, make accessing your AKS clusters a great deal smoother.

What do I mean by “poor user experience”? In the same vein as comparable offerings from AWS (EKS) and Google Cloud (GKE), AKS leverages Azure’s identity and access management (IAM) functionality, so that users have a single place to manage user and group entities. This makes perfect sense! What doesn’t make sense to me, though, is the requirement that users must perform a separate login process to gain access to the cluster, even if the user is already authenticated via the Azure CLI. This is very counter to both EKS and GKE, where—if you are already authenticated via their CLI tools—no additional steps are necessary to access appropriately-configured managed Kubernetes clusters on their platforms. This change I’ll show you will fix that, and bring Azure’s experience back in line with AWS and Google Cloud.

There are some limitations/caveats to this tweak I’m going to show you:

  • This tweak assumes that you are (or will be) authenticated/logged in with the Azure CLI. If you’re using Pulumi, then this typically going to be the case, although there are other authentication options available.
  • The AKS cluster you wish to connect to using this method must be configured to use AKS-managed Azure AD integration, also referred to as “managed AAD”. (More information here.)

To access a Kubernetes cluster, you need a Kubeconfig file which provides the information on the cluster, the user, and the context (combination of cluster and user). When using Pulumi, there are (at least) two ways of getting a Kubeconfig for an AKS cluster you created:

  1. If you’re using Pulumi’s Azure Native provider, use the listManagedClusterUserCredentials function to retrieve this information (more information here).
  2. After the cluster has been created, use the Azure CLI az aks get-credentials command to retrieve the Kubeconfig.

In both cases, you’ll get a Kubeconfig in which the users section includes a single user. The configuration for that user leverages the exec functionality of the Kubernetes client authentication API to execute a binary named kubelogin (GitHub repository here). It will look something like this (I’ve omitted some lines for the purposes of brevity and clarity):

- name: clusterUser_resourceGroup8355ff6e_aks-clusterad642fc1
      - get-token
      - --environment
      - AzurePublicCloud
      # The --server-id, --client-id, and --tenant-id lines have been omitted
      - --login
      - devicelogin
      command: kubelogin
      env: null
      provideClusterInfo: false

It’s the very last element in the args list that triggers the separate authentication process; this is outlined in the kubelogin repository (see the “Device Code Flow (default)” section).

On that same page, you’ll also see a “Azure CLI token login” that shows you how to change the Kubeconfig to leverage the Azure CLI. This is the change you need to make.

Simply remove the --client-id and --tenant-id lines, and then change devicelogin to azurecli. Once you’ve made that change, when you use kubectl to access the Kubernetes cluster referenced by this Kubeconfig file, you won’t be prompted for a separate authentication process—it will just leverage the existing authentication credentials you’ve obtained via the Azure CLI. This makes the experience on par with EKS and GKE, and far more seamless than the default configuration that uses devicelogin.

Kudos to Pete Cook (@blindpete on Twitter), who pointed me in the direction of the kubelogin GitHub repository after I complained about the user experience with AKS. Thank you, Pete!

I hope this helps some folks out there. I’m not an Azure/AKS expert, so if you are and I’ve misrepresented something here, please let me know so I can correct it. You can reach out to me on Twitter (DMs are open), or find me in any one of a number of Slack communities (I frequent both the Kubernetes Slack community and the Pulumi Slack community). Thanks for reading!

Technology Short Take 160

Welcome to Technology Short Take #160! This time around, my list of links and articles is a tad skewed toward cloud computing/cloud management, but I’ve still managed to pull together some links on other topics that readers will hopefully find useful. For example, did you know about the secret macOS network quality tool? You didn’t? Lucky for you there’s a link to an article about it below. Read on to get all the details!


  • Ivan Pepelnjak tackles the “infrastructure-as-code is scary” mindset. (Related: see the first bullet in the “Career/Soft Skills” section below.)
  • Larry Peterson reflects on the evolution of TCP.
  • Vikas Choudhary discusses Istio’s Secure Naming; that is, the name given to services and the Subject Alternative Name (SAN) put on the X.509 certificates used in mTLS.



Cloud Computing/Cloud Management

Operating Systems/Applications

  • I loved this article by Lawrence Jones about how his organization tested and prepared for the impact of latency on their application. There’s some really good stuff in here.
  • Phil Stokes shares a few macOS “power tricks” for security pros.
  • Devbox looks insanely useful. I haven’t tried it yet, but do plan to try it out in the very near future.
  • Jean Yang opines that traffic-based tools leveraging eBPF are going to shake up the entire developer tools industry.
  • I should add this to my standard SSH bastion host OS image. (Also, I loved the story about the origin of the name.)
  • Here’s a walkthrough on using DNSCrypt on macOS.
  • Dan Petrov writes about the secret macOS network quality tool.
  • This article by Cecelia Martinez almost has me convinced I need to give the GitHub CLI a try (even though that is not the article’s primary purpose).



Career/Soft Skills

That’s it for this time around! If you have feedback for me—you want to suggest a new blog I should follow or check, or you have some constructive criticism that will help me make this site better—I’d love to hear from you. Feel free to reach out to me on Twitter, or find me in one of a number of different Slack communities (the Kubernetes and Pulumi Slack communities are good choices). Thanks for reading!

Referencing Configuration Values in Pulumi YAML

Lately I’ve been doing a fair amount of work with Pulumi’s YAML support (see this blog post announcing it), and I recently ran into a situation where I wanted to read in and use a configuration value (set via pulumi config). When using one of Pulumi’s supported programming languages, like TypeScript or Python or Go, this is pretty easy. It’s also easy in YAML, but not as intuitive as I originally expected. In this post, I’ll share how to read in and use a configuration value when using Pulumi YAML.

Configuration values are how you parameterize a Pulumi program in order to make it more flexible and reusable (see this page on configuration from Pulumi’s architecture and concepts documentation). That same page also has examples of using config.Get or config.Require to pull configuration values into a program (the difference between these two, by the way, is that the latter will prevent a program from running if the configuration value isn’t supplied).

In YAML, it’s (currently) handled a bit differently. As outlined in the Pulumi YAML reference, a Pulumi YAML document has four main sections: configuration, resources, variables, and outputs. At first, I thought I’d have to use the variables section along with the Fn::Invoke function, which allows users to “call” or “invoke” some sort of programmatic function, like looking up information from a provider or similar. There are other functions as well, like Base64 encoding or decoding.

As it turns out, though, it’s actually the configuration section that is what you need to read in and use a configuration value. This seems obvious now in retrospect, but it didn’t seem obvious at first. In my case, I wanted to read in and use a configuration value for the underlying provider, like the azure-native:location configuration value used by the Azure Native provider. Here’s what’s needed:

    type: String

Omitting a default: <some value> line from the stanza above, like I did, means that this is a required value (i.e., it is analogous to using config.Require in a programming language).

That’s only half the picture, though. To then later reference this value somewhere else, you use the standard Pulumi YAML interpolation syntax. Continuing the example of using the azure-native:location configuration value, here’s how you would reference that configuration value when creating an Azure resource group:

    type: azure-native:resources:ResourceGroup
      location: ${azure-native:location}
      resourceGroupName: scotts-rg

While this example shows using a provider configuration value (the azure-native:location value), it is equally applicable to any sort of configuration value you need to pass in and reference in a Pulumi YAML document.

I hope this proves useful to someone out there. If you have questions, feel free to reach out to me on Twitter, or come find me in the Pulumi community Slack.

Managing AWS Key Pairs with Pulumi and Go

As I was winding down things at Kong and getting ready to transition to Pulumi (more information on why I moved to Pulumi here), I casually made the comment on Twitter that I needed to start managing my AWS key pairs using Pulumi. When the opportunity arose last week, I started doing exactly that! In this post, I’ll show you a quick example of how to use Pulumi and Go to declaratively manage AWS key pairs.

This is a pretty simple example, so let’s just jump straight to the code:

_, err := ec2.NewKeyPair(ctx, "aws-rsa-keypair", &ec2.KeyPairArgs{
	KeyName:   pulumi.String("key-pair-name"),
	PublicKey: pulumi.String("<ssh-key-material-here>"),
	Tags: pulumi.StringMap{
		"Owner":   pulumi.String("User Name"),
		"Team":    pulumi.String("Team Name"),
		"Purpose": pulumi.String("Public key for authenticating to AWS EC2 instances"),
	if err != nil {
		return err

This code is, by and large, pretty self-explanatory. For PublicKey, you just need to supply the contents of the public key file (use cat or similar to get the contents of the file) where it shows <ssh-key-material-here>. Then specify an appropriate name and adjust the tags as desired. In this particular case, I’m “throwing away” the reference to the newly-created key pair (note the _, err := ec2.NewKeyPair; the underscore indicates I’m discarding that value) because I don’t need to refer to it anywhere else. If I did need to refer to it elsewhere (say, I was going to create a new key pair and launch an instance in the same Pulumi program), then I’d want to catch that return value.

For more information, the API docs for this resource are found here.

In the event you’re wondering how this snippet of code manages key pairs in multiple regions…well, that’s where stacks come into play. You can create multiple stacks for any Pulumi project (including this one), and each stack can target a specific AWS region. This is exactly the approach I’m using. For completeness’ sake, the process looks something like this:

  1. Run pulumi stack init to create a new stack. Specify the name of the new stack.
  2. Run pulumi config set aws:region <asw-region>, replacing <aws-region> with the name of the AWS region this stack should target.
  3. Run pulumi up and you’re good to go.

I hope this example is useful to someone. If you have any questions, feel free to reach out to me on Twitter or find me in the Pulumi community Slack (sign up for the Pulumi community Slack here if you don’t already have an account).

Recent Posts

Technology Short Take 159

Welcome to Technology Short Take #159! If you’re interested in finding some links to articles around the web on topics like WASM, Git, Sigstore, or EKS—among other things—then you’ve come to the right place. I’ve spent the last few weeks collecting articles I think you’ll find useful, gleaning them from the depths of Twitter, RSS feeds, Reddit, and Slack. Enjoy, and never stop learning!


Jumping Off Cliffs

For quite a few years, I’ve had this desktop wallpaper that I really love. I don’t even remember where I got it or where it came from, so I can’t properly attribute it to anyone. I use this wallpaper from time to time when I want to be reminded to challenge myself, to learn new things, and to step outside of what is comfortable in order to explore the as-yet-unknown. Looking at this wallpaper on my desktop a little while ago, I realized that I may have started taking the inspirational phrase on this wallpaper for granted, instead of truly applying it to my life.


Technology Short Take 158

Welcome to Technology Short Take #158! What do I have in store for you this time around? Well, you’ll have to read the whole article to find out for sure, but I have links to articles on…well, lots of different topics! DNS, BGP, hardware-based security, Kubernetes, Linux—they’re all in here. Hopefully I’ve managed to find something useful for someone.


Revisiting X.509 Certificates in Kubeconfig Files

In 2018, I wrote an article on examining X.509 certificates embedded in Kubeconfig files. In that article, I showed one way of extracting client certificate data from a Kubeconfig file and looking at the properties of the client certificate data. While there’s nothing technically wrong with that article, since then I’ve found another tool that makes the process a tad easier. In this post, I’ll revisit the topic of examining embedded X.509v3 certificates in Kubeconfig files.


Posts from the Past, August 2022

I thought I might start highlighting some older posts here on the site through a semi-regular “Posts from the Past” series. I’ll start with posts published in the month of August through the years. Here’s hoping you find something that is useful (or perhaps entertaining, at least)!


Site Category Changes

This weekend I made a couple of small changes to the categories on the site, in an effort to make navigation a bit more intuitive. In the past, readers had expressed some confusion over the “Education” and “Explanation” categories, and—to be frank—their confusion was warranted. I also wasn’t clear on the distinction between those categories, so this post explains the changes I’ve made.


Using Default AWS Resources with Pulumi

Per the AWS documentation (although I’m sure there are exceptions), when you start using AWS you are given some automatically-created resources: a default VPC that contains public subnets in each availability zone in the region along with an Internet gateway and settings to enable DNS resolution. Most of the infrastructure-as-code tutorials that I’ve seen start with creating a VPC and subnets and gateway, but what if you wanted to use these default resources instead? I wasn’t really able to find a good walkthrough on how to do this, so this post provides some sample Go code you can use with Pulumi to identify these default AWS resources and use them.


Technology Short Take 157

Welcome to Technology Short Take 157! I hope that this collection of links I’ve gathered is useful to someone out there. In particular, the “Career/Soft Skills” section is a bit bigger than usual this time around, as is the “Security” section.


Network Programmability and Automation, Second Edition

In late 2015, I was lucky enough to be part of a small crew of authors who launched a new book project targeting “next-generation network engineering skills.” That book, Network Programmability and Automation, was published by O’Reilly and has garnered praise and accolades for tackling head-on the topics that network engineers should consider mastering as the field of network engineering continues to grow and evolve. I was excited about that announcement, and I’m even more excited to announce that the early release of the second edition of Network Programmability and Automation is now available!


Technology Short Take 156

Welcome to Technology Short Take #156! It’s been about a month since the last Technology Short Take, and in that time I’ve been gathering links that I wanted to share with my readers. (I still have quite the backlog of links to read!) Hopefully something I share here will prove useful to someone. Enjoy the links below, and enjoy your weekend!


Making Flatpak Firefox use Private Browsing by Default

In April 2021 I wrote a post on making Firefox use Private Browsing by default, in which I showed how to modify the GNOME desktop file so that Firefox would open private windows by default without restricting access to normal browsing windows and functionality. I’ve used that technique on all my Fedora-based systems since that time, until just recently. What happened recently, you ask? I switched to the Flatpak version of Firefox. Fortunately, with some minor tweaks, this technique works with the Flatpak version of Firefox as well. In this post, I’ll share with you the changes needed to make the Flatpak version of Firefox also use private browsing by default.


Git Difftool and Meld as a Flatpak

I’ve recently started migrating many of the applications on my Fedora 36 laptop to their Flatpak versions. For the most part, this has been pretty straightforward, although there isn’t really any method for migrating configuration and data. Today I ran into a problem with Meld, a graphical diff utility, and using it with the git difftool command. Below I’ll share how I worked around this problem.


Technology Short Take 155

Welcome to Technology Short Take #155, just in time for the 2022 Memorial Day holiday weekend! (Here in the US, at least.) I mean, don’t you want to spend this weekend catching up on some technology-related articles instead of cooking on the grill and gathering with friends and family? I certainly hope not! Still, for those who need a little technology fix over the weekend, hopefully I’ve included something useful in the list of articles below. Enjoy!


Fine-Tuning Control Plane Access with Cluster API

When Cluster API creates a workload cluster, it also creates a load balancing solution to handle traffic to the workload cluster’s control plane. This is necessary so that the control plane endpoint is decoupled from the underlying control plane nodes (which facilitates scaling the control plane, among other things). On AWS, this mean creating an ELB and a set of security groups. For flexibility, Cluster API provides a limited ability to customize this control plane load balancer. In this post, I’ll show you how to use this functionality to fine-tune access to a workload cluster’s control plane when using Cluster API with AWS.


Technology Short Take 154

Welcome to Technology Short Take #154! My link of links and articles from around the Internet is a bit light on networking and virtualization this time around, but heftier in the security, cloud, and OS/application sections. I hope that I’ve managed to include something that you’ll find useful. Enjoy the content!


Older Posts

Find more posts by browsing the post categories, content tags, or site archives pages. Thanks for visiting!