Cloud-Native Security Architecture: Patterns for Microservices and Kubernetes

Cloud-native security operates on different assumptions than traditional security:

Traditional model:

• Trust the network perimeter; distrust outside
• North-south traffic (ingress/egress) is inspected; east-west traffic (service-to-service) is trusted
• Credentials are long-lived and stored in config files
• Security controls are applied to VMs by configuration management

Cloud-native zero trust model:

• No implicit trust based on network location -- every request is authenticated regardless of origin
• East-west traffic is mutually authenticated and encrypted (service mesh mTLS)
• Credentials are short-lived and dynamically injected -- never stored in images or env files
• Security policy is code (OPA, Kyverno) -- enforced at admission time and runtime
• Workloads have cryptographic identities (SPIFFE/SPIRE) -- not IP-based trust

Security architecture layers:

┌─────────────────────────────────────────────────────┐
│  Supply Chain Security                               │
│  (Image signing, SBOM, trusted registries)           │
├─────────────────────────────────────────────────────┤
│  Admission Control (Policy-as-Code)                  │
│  (OPA/Gatekeeper, Kyverno -- what can run)           │
├─────────────────────────────────────────────────────┤
│  Workload Identity & Service-to-Service Auth         │
│  (SPIFFE/SPIRE, service mesh mTLS)                   │
├─────────────────────────────────────────────────────┤
│  Secrets Management                                  │
│  (Vault injection, External Secrets Operator)        │
├─────────────────────────────────────────────────────┤
│  Network Policy (Microsegmentation)                  │
│  (Kubernetes NetworkPolicy, Cilium)                  │
├─────────────────────────────────────────────────────┤
│  Runtime Security (Anomaly Detection)                │
│  (Falco, Sysdig -- what is actually happening)       │
└─────────────────────────────────────────────────────┘

Each layer is independently valuable but the combination provides defense-in-depth: if an attacker bypasses supply chain controls and gets a malicious image running, admission control limits what it can do; if it bypasses admission control, network policy limits what it can reach; if it bypasses network policy, it cannot get secrets; if it somehow gets secrets, runtime detection alerts on anomalous behavior.

A service mesh is an infrastructure layer that handles service-to-service communication. Security-relevant capabilities: mutual TLS (mTLS) for all east-west traffic, traffic policies (which services can communicate with which), and observability (every request logged with full context).

How mTLS works in a service mesh:

Each pod gets a sidecar proxy (Envoy in Istio, Linkerd proxy) that intercepts all inbound and outbound traffic. The proxy presents a certificate identifying the service -- issued by the mesh's certificate authority, derived from the Kubernetes service account. Certificates rotate automatically (every 24 hours by default in Istio).

Without mTLS: Service A calls Service B over plaintext HTTP. Any pod in the cluster can make the same call. There is no authentication of the caller.

With mTLS: Service A's Envoy proxy presents its certificate to Service B's Envoy proxy. B's proxy verifies A's certificate against the mesh CA. Only if the certificate is valid and the authorization policy allows A to call B does the request succeed.

Istio mTLS setup:

# Enable strict mTLS across the entire mesh (no plaintext allowed)
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system  # applies mesh-wide
spec:
  mtls:
    mode: STRICT  # reject any non-mTLS connection

---
# Authorization policy: only the payment service can call the database service
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: db-access-policy
  namespace: data
spec:
  selector:
    matchLabels:
      app: postgres
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/payments/sa/payment-service"]
      to:
        - operation:
            ports: ["5432"]

Linkerd as a simpler alternative:

Linkerd is a CNCF project with a smaller operational footprint than Istio. It enables mTLS by default upon installation with minimal configuration:

# Install Linkerd
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -

# Inject Linkerd sidecar into a namespace (enables mTLS for all pods)
kubectl annotate namespace payments linkerd.io/inject=enabled

# Verify mTLS is active
linkerd viz stat deployment -n payments

Service mesh comparison:

Kubernetes admission controllers validate and mutate resources before they are persisted to etcd. Policy-as-code tools implement admission control as declarative policies -- preventing insecure workloads from running rather than detecting and alerting after the fact.

OPA (Open Policy Agent) with Gatekeeper:

# Install Gatekeeper
kubectl apply -f https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper.yaml

# Create a constraint template: require non-root containers

apiVersion: templates.gatekeeper.sh/v1
kind: ConstraintTemplate
metadata:
  name: k8srequirenonroot
spec:
  crd:
    spec:
      names:
        kind: K8sRequireNonRoot
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package k8srequirenonroot
        violation[{"msg": msg}] {
          container := input.review.object.spec.containers[_]
          container.securityContext.runAsNonRoot != true
          msg := sprintf("Container %v must run as non-root", [container.name])
        }
---
# Apply the constraint to all pods
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sRequireNonRoot
metadata:
  name: require-non-root
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]

Essential Gatekeeper / Kyverno policies:

Kyverno (simpler alternative to OPA for Kubernetes-specific policies):

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
spec:
  validationFailureAction: Enforce
  rules:
    - name: check-privileged
      match:
        resources:
          kinds: [Pod]
      validate:
        message: "Privileged containers are not allowed."
        pattern:
          spec:
            containers:
              - securityContext:
                  privileged: "false | ~X"

Static secrets (passwords in config files, API keys in environment variables baked into images) are the most common cause of cloud-native credential exposure.

Anti-patterns to eliminate:

# Never: hardcoded in Deployment manifest
env:
  - name: DB_PASSWORD
    value: "supersecret123"

# Never: from Kubernetes Secret as env var (stored in etcd unencrypted by default)
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password

Recommended: Vault Agent Injector

HashiCorp Vault injects secrets directly into the pod filesystem at startup via an init container and sidecar, with no Kubernetes Secrets created:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
spec:
  template:
    metadata:
      annotations:
        # These annotations trigger Vault injection
        vault.hashicorp.com/agent-inject: "true"
        vault.hashicorp.com/role: "payment-service"
        vault.hashicorp.com/agent-inject-secret-config: "database/creds/payment-db"
        vault.hashicorp.com/agent-inject-template-config: |
          {{- with secret "database/creds/payment-db" -}}
          DB_USER={{ .Data.username }}
          DB_PASSWORD={{ .Data.password }}
          {{- end }}
    spec:
      serviceAccountName: payment-service  # Vault authenticates via K8s service account JWT
      containers:
        - name: payment-service
          # App reads /vault/secrets/config at startup -- no env vars needed

External Secrets Operator:

ESO syncs secrets from external stores (AWS Secrets Manager, Azure Key Vault, GCP Secret Manager) into Kubernetes Secrets -- with automatic rotation:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: payment-db-secret
spec:
  refreshInterval: 1h  # sync every hour (picks up rotated secrets)
  secretStoreRef:
    name: aws-secretsmanager
    kind: ClusterSecretStore
  target:
    name: payment-db-secret  # creates this Kubernetes Secret
  data:
    - secretKey: password
      remoteRef:
        key: production/payment-db
        property: password

Workload Identity (IRSA / Workload Identity Federation):

Rather than storing cloud credentials in secrets, bind Kubernetes service accounts to cloud IAM roles directly:

# AWS IRSA: annotate the service account with the IAM role ARN
apiVersion: v1
kind: ServiceAccount
metadata:
  name: payment-service
  namespace: payments
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789:role/payment-service-role
# The pod can now call AWS APIs as this role -- no credentials stored anywhere

Kubernetes Network Policies:

By default, all pods can communicate with all other pods in a cluster. Network policies implement microsegmentation at the Kubernetes level:

# Default deny all ingress and egress for a namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: payments
spec:
  podSelector: {}  # applies to all pods
  policyTypes:
    - Ingress
    - Egress
---
# Allow: payment-service can receive traffic from api-gateway only
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: payment-service-ingress
  namespace: payments
spec:
  podSelector:
    matchLabels:
      app: payment-service
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: api-gateway
          podSelector:
            matchLabels:
              app: api-gateway
      ports:
        - protocol: TCP
          port: 8080

Cilium for L7 network policy:

Kubernetes native NetworkPolicy operates at L3/L4. Cilium (eBPF-based) adds L7 enforcement -- allowing or denying specific HTTP methods, paths, and headers:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
spec:
  description: "Only allow GET /api/v1/products from frontend"
  endpointSelector:
    matchLabels:
      app: product-service
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: "8080"
          rules:
            http:
              - method: GET
                path: /api/v1/products

Runtime security with Falco:

Falco detects anomalous container behavior by monitoring Linux system calls:

# Custom Falco rule: alert if any container reads /etc/shadow
- rule: Read shadow file in container
  desc: An attempt to read /etc/shadow in a container
  condition: >
    open_read and container and fd.name = /etc/shadow
  output: >
    Shadow file read in container (user=%user.name command=%proc.cmdline
    container=%container.name image=%container.image)
  priority: CRITICAL
  tags: [container, credential-access]

# Built-in rules catch:
# - Shell spawned in a container (rare in production -- indicates attacker pivot)
# - Outbound connection to non-expected destination
# - Cryptominer process patterns
# - /proc filesystem access (reconnaissance indicator)