All posts

Secure Kubernetes Secrets with GPG and kubectl

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 secr

Free White Paper

Kubernetes RBAC + VNC Secure Access: The Complete Guide

Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.

Free. No spam. Unsubscribe anytime.

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:

  1. Generate a GPG key pair with gpg --full-generate-key.
  2. Encrypt sensitive Kubernetes manifests with gpg --recipient <KEY_ID> --encrypt file.yaml.
  3. Store only the .gpg files in your repo.
  4. 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.

Continue reading? Get the full guide.

Kubernetes RBAC + VNC Secure Access: Architecture Patterns & Best Practices

Free. No spam. Unsubscribe anytime.

Using GPG with kubectl also makes compliance simpler. You can prove that plaintext secrets never existed in your source control. Every decryption can be logged and audited. If a contractor leaves the team, remove their public key and re-encrypt—no need to rotate the cluster credentials themselves.

This approach removes the gap between secure secret storage and Kubernetes deployment. It avoids the complexity of external secret managers for smaller setups, while still enforcing encryption-at-rest and in-transit for sensitive manifests. For larger teams, GPG encryption can be one layer in a hardened deployment model alongside tools like Sealed Secrets or SOPS.

Stop leaking credentials to logs, and stop wondering who can see your configs. GPG and kubectl make security a habit instead of an afterthought.

See it live in minutes at hoop.dev and secure your Kubernetes workflows today.

Get started

See hoop.dev in action

One gateway for every database, container, and AI agent. Deploy in minutes.

Get a demoMore posts