Kubernetes Secrets and Policies | A Security Guide

As Kubernetes becomes more widely adopted, it’s really important to make sure the apps running inside it are safe. Kubernetes is great for managing and scaling apps, but it doesn’t automatically keep everything secure.
When I first started learning Kubernetes, I mainly focused on getting things to work — like creating deployments, services, and setting up ingress. But later I realized that not securing the apps properly or using secrets in plain text could be dangerous. That’s when I started learning about two key parts of Kubernetes security: Network Policies and Secrets Management.
In this blog, Kubernetes: Secrets and Policies, I’ll share what I learned and show you, step by step, how to use these features to make your Kubernetes apps more secure

Why Kubernetes Security Matters

Kubernetes makes it easy to run apps, but if we don’t set up security the right way, attackers can break in, steal data, or take control of our apps. This can happen if:

• Apps talk to each other without limits
• Secrets like passwords or API keys are exposed
• Anyone can access the cluster without control

That’s why it’s important to secure traffic, manage access, and protect sensitive data right from the start.

Understanding Network Policies

Basically, Network Policies in Kubernetes help you control who can talk to whom inside your cluster.

What Are Network Policies?

By default, every pod in Kubernetes can freely connect to any other pod. However, this openness poses a security risk. To address this, a Network Policy acts like a set of traffic rules. In simple terms, it says:

• “Only the frontend can talk to the backend.”
• “Deny everything else.”

Think of it like setting up walls between rooms in a house—you decide which doors stay open.

Use Network Policies when:

• You restrict access to sensitive apps (like databases) so that only specific services can reach them.
• You follow a zero-trust security model by allowing only the necessary connections.
• You need to follow company or industry security rules.

Implementing Network Policies

Now that we understand what Network Policies are, let’s see how to write and use them in Kubernetes.

A Network Policy is just a YAML file, like other Kubernetes resources. Here’s the basic structure:

Without a policy:

• Frontend pod can talk to backend
• Backend can talk to database
• But also: Any other random pod can talk to database

With a policy:

• Only specific pods (like backend) can talk to the database ✅

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-db
  namespace: your-namespace
spec:
  podSelector:
    matchLabels:
      app: database
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: backend

This policy applies to all pods with label app: database. It only allows traffic coming from pods with label app: backend. Everything else is blocked.

To apply this YAML:

kubectl apply -f your-policy.yaml

How I Tested this:

• I created 3 pods: frontend, backend, and database.
• Applied the policy.
• Tried to curl the DB from frontend: Connection refused. ✅ Policy worked!

For a deeper dive, you can check out the official Kubernetes Network Policies documentation.

Managing Secrets in Kubernetes

Secrets in Kubernetes help you store sensitive data like passwords, API keys, or tokens safely. They’re stored in etcd. But by default, they’re only base64-encoded—not encrypted. If someone gets access to etcd, they can decode and see your secrets in plain text.

Instead of hardcoding these values in your app or YAML files, you keep them in a secret and reference them when needed.

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: YWRtaW4=      # base64 encoded 'admin'
  password: cGFzc3dvcmQ=  # base64 encoded 'password'

To decode:

echo YWRtaW4= | base64 --decode

Best Practices for Handling Kubernetes Secrets

Discover best practices for Securing Kubernetes: Secrets and Policies to protect data, control access, and harden your cloud-native apps.

• Use RBAC (Role-Based Access Control): RBAC lets you control who can do what in your Kubernetes cluster. For example, only the DevOps team or trusted admins should be able to see or change secrets.
• Avoid checking secrets into Git: Never store your passwords or keys directly in your code repository. Even if your repo is private, it can be accessed by others or hacked.
• Use environment variables or volume mounts: Your app needs secrets (like passwords) to work, but don’t hardcode them. Instead, Kubernetes can inject secrets as environment variables or files inside containers.
• Enable encryption at rest: By default, Kubernetes stores secrets in etcd as plain text.You should turn on encryption to save secrets encrypted on disk. This way, if someone accesses the underlying data store (etcd), they cannot read the secrets without the encryption key, protecting sensitive data from exposure.

Conclusion

Securing Kubernetes apps is essential to protect your data. Use Kubernetes Network Policies to control traffic and manage Secrets carefully to keep sensitive info safe. Furthermore, follow best practices like RBAC, avoiding secrets in code, and enabling encryption. Security is ongoing—keep improving to stay safe.