How are you managing kubeconfig files on your workstation, and what precautions do you take when running kubectl or similar tools? For people who work on applications while also administering clusters, how have you protected access credentials against supply-chain malware or other software running with your user permissions?
4 Answers
You can also keep a kubeconfig template or configuration in a version-controlled project and use Dex or another OpenID Connect provider with an external identity system for login. The important part is avoiding embedded, durable credentials in the file.
Encrypting the file alone does not solve much if malware is already running as your user, because it may be able to use the file after you decrypt it. The stronger defense is making stolen credentials expire quickly. Use OIDC authentication with short-lived tokens—hours rather than a client certificate that remains valid for a year—so a compromised workstation creates a much smaller window of access.
Use an identity provider such as Okta with SSO and short-lived tokens. That way, the kubeconfig contains connection and authentication settings but no long-term static credentials.
One option is to keep the kubeconfig encrypted with SOPS and protect the decryption key using age, with that key stored in a password manager. Local environment tooling can prompt for authentication when you need to use kubectl, k9s, or similar clients.
The identity-provider configuration can be managed alongside the rest of the cluster configuration, which makes the setup reproducible without checking long-lived secrets into the project.