In Part 3 we enabled the OIDC auth method and the two Kubernetes secrets engines, but they were not yet connected to anything real. In this post we wire everything together using only the EC2 public DNS name for external references. We configure Vault OIDC to trust Keycloak, we tell...
Read moreIn Part 1 you explored auth methods, secrets engines, and policies with a local dev server. Now you will build the actual lab environment on an AWS EC2 instance: Keycloak for identity, a Vault server reachable from your laptop, and two separate kind clusters. Everything you do here sets the...
Read moreIn Part 2 you provisioned the lab on EC2: Keycloak on 8080, Vault listening on all interfaces at 8200, and two kind clusters. Now you will configure identity in Keycloak and enable the two building blocks in Vault (OIDC auth and the Kubernetes secrets engines) that will later let a...
Read moreIn Part 4 you ran vault login -method=oidc role=human, then copied service_account_token from vault write k8s-*/creds/… into kubectl --token …. This final post removes that copy step with a small kubectl credential plugin. It picks the target cluster from your context, reuses a valid Vault token when possible, opens the...
Read moreLet's begin by launching a Vault development server and exploring the core building blocks you'll use throughout this series: authentication methods, secrets engines, paths, and policies. Everything is kept deliberately simple so you can clearly see how these pieces fit together — before you swap in OIDC from Keycloak and...
Read more