A comprehensive guide to the best practices for managing secrets in K8s

As a DevOps or platform engineer, you know the pain of managing Kubernetes Secrets. Rotating secrets with kubectl is a nightmare, especially across multiple clusters. You spend half your time fixing RBAC permissions and the other half explaining to teams why they shouldn't paste secrets into their Dockerfiles or log them to stdout. Just when you think everything's secure, someone drops a database password into a ConfigMap, and the cycle starts all over again!

At Infisical, we've stopped counting how many times we’ve heard this complaint: "Why is K8s secrets management still so hard?"

This blog post is a follow up on my early 2023 Medium article A better way to manage secrets in Kubernetes, which generated significant interest back then. But it was time for a refresher! The Kubernetes secrets landscape has evolved, but not necessarily simplified. With the widespread adoption of microservices and multi-cloud architectures, secrets management has become more critical than ever.

Let's examine the current state of Kubernetes secrets management in 2025. But first, a quick review of the fundamentals.

What is a Kubernetes Secret?

At its core, a K8s Secret is just a way to keep sensitive data separate from your application code. Instead of hardcoding credentials in your pod specs or baking them into container images (we've all seen those password literals in Dockerfiles), Secrets give you a dedicated place to store this sensitive stuff.

https://kubernetes.io/docs/concepts/configuration/secret/

You can use Secrets by mounting them as files or injecting them as environment variables into your pods. While this makes managing credentials cleaner, here's the catch - K8s Secrets are just base64 encoded and stored in etcd by default. And no, base64 is not encryption, despite what some might think. You'll need extra security measures to properly lock things down.

Now, let's look at how to work with these Secrets in practice.

How to Handle K8s Secrets?

Option 1: The Manual Way (Not Recommended for Production)

The most basic approach is creating secrets by hand through kubectl:

kubectl create secret generic my-secret --from-literal=username=myuser --from-literal=password=mypassword

Or you can write a YAML file (after base64 encoding your values):

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: bXl1c2Vy
  password: bXlwYXNzd29yZA==

Then apply it:

kubectl apply -f my-secret.yaml

As already mentioned, once created, you've got two ways to use these secrets in your pods:

Mount them as files using volumes (each secret key becomes a file)
Inject them as environment variables

(ok, three if we take into account the secret needed to authenticate with private container registries)

Rating: ⭐ (Avoid at all Costs in Production)

Why: Let's be real - how are you sharing that YAML file with your team? Storing base64-encoded secrets in version control is about as secure as writing your passwords on sticky notes. Plus, as mentioned, this technique doesn’t scale at all.

Option 2: The GitOps Way (Encrypted Secrets)

A step up from plain YAML files is encrypting your secrets with tools like Sealed Secrets or SOPS before committing them to git. The concept is very similar: you first encrypt the sensitive values using their respective CLIs (kubeseal or sops), making them safe to commit to git. These encrypted resources can then be synced to your cluster using GitOps tools like ArgoCD, where dedicated controllers handle the decryption into standard Kubernetes secrets.

This solves the "secrets in plain text" problem, but brings its own headaches: how do you manage the encryption key?

Rating: ⭐⭐ (Workable but Complex)

Why: Sure, you can sleep better knowing your secrets aren't sitting in git as base64, but now you're managing key management systems (KMS) across clusters and clouds. Try rotating these keys across multiple environments or switching cloud providers - suddenly your "solution" feels like a second job. And good luck onboarding new team members or explaining the encryption workflow to developers who just want their apps to work.

Option 3: Secrets Operators (The Enterprise Approach)

Here's where things get serious. Using a secrets operator like External Secrets Operator (ESO) lets you handle secrets the way they should be handled in production Kubernetes environments. Instead of managing secrets directly in K8s, you're connecting to purpose-built secret vaults and managers - think HashiCorp Vault, AWS Secrets Manager, or Infisical.

What makes this approach solid:

Your sensitive secrets live in actual vaults, not in etcd (where you can configure encryption at rest)
You get audit logs and version tracking
Automatic secret rotation (no more manual updates)
Granular RBAC controls
Works across multiple clusters and environments
Not locked into one cloud provider
One place to manage all secrets (if done right)

Rating: ⭐⭐⭐⭐ (The Production-Ready Choice)

Why not perfect? ESO's flexibility comes with complexity - it can be clunky to set up and use. Plus, it's missing a crucial feature: automatic pod redeployment when secrets change (it's no coincidence that Infisical built their own operator to solve this.) Still, for most production environments, this is your best bet.

Option 3.5: Infisical's Native Operator (The Secret Weapon)

Our operator takes everything good about the generic operators but removes the setup headaches and adds that missing killer feature: automatic pod redeployment when secrets change.

Why it's a secret weapon:

Zero gymnastics to set up - it just works
Auto-redeployment when secrets update (finally!)
Seven different auth methods - from OIDC to cloud provider IAM
True zero-trust setup: no more "secret zero" bootstrap problems
Native integration means better performance
Streamlined developer experience
All the enterprise features you'd expect (audit logs, RBAC, multi-env support)
None of the generic operator complexity

Rating: ⭐⭐⭐⭐⭐ (The "Why Didn't This Exist Before?" Choice)

If you're already using Infisical, this is a no-brainer upgrade from ESO. If you're not, it's a compelling reason to consider switching. It's what happens when you build an operator (yes, it’s maintained by us) specifically to solve real-world K8s secrets headaches instead of trying to be everything to everyone.

Try Infisical's K8s Operator Now - Available in Free Tier

And here's the cherry on top - as of now, we also offer native CSI driver integration. Want to skip Kubernetes Secrets entirely and mount your secrets directly as files in your pods? Done. No more secrets flying around in your cluster. This means better security posture - your secrets only exist where they're actually needed, reducing attack surface.

We don’t say this is the way, but if you want to completely avoid native K8s secrets, then CSI is for you.

After reviewing all these options, you might be wondering about security best practices for Kubernetes secrets management. Let's conclude with a practical checklist of what matters - and how modern tools can handle the heavy lifting for you.

Best Practices for Kubernetes Secrets Management

If you've been searching for K8s secrets best practices, you'll find the same recommendations everywhere:

Implement proper RBAC controls
Rotate secrets regularly
Use encryption at rest
Enable audit logging
Follow least privilege access
Integrate with identity providers
Never store secrets in plain text
Keep secrets isolated by environment

Here's the thing - while these are solid guidelines, implementing them manually is a massive undertaking. That's exactly why we built these practices directly into Infisical's design:

Principle of Least Privilege: Fine-grained control through secretsScope - teams only see and access the secrets they need
Automated Fetching: Set it and forget it with resyncInterval parameter - up-to-date secrets everywhere
Identity Federation: Native integration with your existing auth setup - whether that's AWS IAM, OIDC, or other major identity providers, Infisical can use your current infra platform for identity.
Audit Trail: Every secret access and change is automatically tracked and logged - no extra configuration needed
Secret Zero Addressed: When using cloud provider authentication, you can finally eliminate long-lived credentials entirely

The best security practice is the one that's automated and enforced by default. Instead of building this security layer yourself, you get it out of the box.

Wrapping Up

As we head into 2025, managing Kubernetes secrets doesn't have to be the headache it once was. The days of manually managing base64-encoded YAML files or wrestling with complex key management systems are behind us - modern solutions like Infisical's native operator show that we can have both security and simplicity. Whether you're running a small cluster or managing enterprise-scale deployments, the key is choosing a solution that enforces security best practices by default while keeping your developers productive. The future of K8s secrets management is automated, integrated with your existing identity stack, and most importantly, actually usable.

Ready to Fix Your K8s Secrets Headaches? Get Started Free with Infisical's Operator

Kubernetes Secrets Management in 2025 - A Complete Guide (with Best Practices)