When working with Kubernetes at scale, secure automation matters more than speed. GPG and kubectl together create a simple, auditable path for managing sensitive configuration without storing secrets in plaintext. Many teams rely on kubectl to apply manifests and manage cluster resources. But plain YAML in a repo often holds credentials. That is a risk you cannot afford.
With GPG, you can encrypt Kubernetes config files before committing to Git. You decrypt them only at apply time, keeping secrets safe even if the repository is public. The workflow is direct: use gpg --encrypt for secrets, commit encrypted files, then gpg --decrypt and pipe them into kubectl apply -f -. This means the secret never hits disk in plaintext during CI/CD.
Integrating GPG with kubectl is straightforward on any machine with both installed. You can:
- Generate a GPG key pair with
gpg --full-generate-key. - Encrypt sensitive Kubernetes manifests with
gpg --recipient <KEY_ID> --encrypt file.yaml. - Store only the
.gpgfiles in your repo. - Decrypt just-in-time with
gpg --decrypt file.yaml.gpg | kubectl apply -f -.
This pattern works with GitOps pipelines as well. In automated runs, store the private key in your CI system’s secure store. Import it with gpg --import during the build, then run your decrypt-and-apply command. Because GPG encrypts with public keys, multiple operators can apply changes without sharing the main private key. Revoking or rotating keys becomes a clean step with no downtime.