In this post, I’ll demonstrate how to configure an Azure App Registration with federated credentials and configure OAuth2 Proxy to use Kubernetes-issued workload identity tokens to authenticate itself during an OpenID Connect login flow.
Workload Identity Federation is rapidly becoming the modern standard for authenticating workloads. In this post, I will configure the Crossplane AzureAD provider to use a Kubernetes-issued service account token to authenticate to Azure, eliminating the need for long-lived secrets.
In this blog post, I’ll walk you through an example of creating an Azure App Registration with a Federated Credential that trusts tokens issued by my Kubernetes cluster. I’ll then exchange that token for an Azure token and use it to make an API call to retrieve information about my own user.
In this blog post, I’ll show how to set up Workload Identity Federation between a non-GKE Kubernetes cluster and Google Cloud Platform. This setup allows an application running in Kubernetes to use its Kubernetes service account to impersonate a Google service account and access cloud resources.
With Mirrord you can intercept traffic for your pods in your Kubernetes cluster, which allows you to develop your application locally as if it was deployed in your cluster. Utilizing the pods network, environment or even the filesystem. In this post I will be writing some examples that I personally use.
You can extend Kubernetes with your own custom objects, but before you can do that you will need create a Custom Resource Definition so that Kubernetes knows what the object is allowed to look like. In this post I will create a very simple Kubernetes CRD for a Book kind using Rust and kube-rs.
Using a Google service account in your GKE cluster is easy, just create the credential file, apply it as a secret and it's ready for use. But now you have a long lived credential that, if compromised, can be used from anywhere any time. Instead you can use a Kubernetes service account and Google Workload Identity to authenticate to Google Cloud. No need for credential files anymore.
With External DNS for Kubernetes you can automate the creation of DNS records based on an ingress resource. This is a great feature to have, especially in a dynamic development environment. You could have pipelines deploy feature branches which create ingress hostnames based on the branch name and let External DNS create DNS entries for them.
In this tutorial I will setup Pinniped, a Single Sign-on solution from the VMware Tanzu project. Pinniped gives you a unified login experience across all your clusters, including on-premises and managed cloud environments.
In this tutorial I will setup Pomerium as an authentication proxy, with OpenID Connect, for the Kubernetes API. Since Pomerium will be functioning as a proxy for the KubeAPI, you can do this on a managed as well as an unmanaged cluster.