Configuration, Security
& RBAC

Our Journey Today

ConfigMaps: The Settings Panel for Your Apps

Think of a ConfigMap like the settings panel on your phone. You don't rebuild the phone to change the ringtone — you just change the setting. ConfigMaps let you do the same for containers.

Creating ConfigMaps — Four Ways

# From literal key-value pairs
kubectl create configmap app-settings \
  --from-literal=DB_HOST=postgres.db.svc \
  --from-literal=LOG_LEVEL=info

# From a file (key = filename, value = file content)
kubectl create configmap nginx-conf --from-file=nginx.conf

# From an env file
kubectl create configmap env-config --from-env-file=.env

# From YAML (declarative, GitOps-friendly)
kubectl apply -f configmap.yaml

Declarative ConfigMap YAML

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-settings
data:
  DB_HOST: "postgres.db.svc"
  LOG_LEVEL: "info"
  MAX_CONNECTIONS: "100"
immutable: true  # optional

spec:
  containers:
  - name: app
    envFrom:
    - configMapRef:
        name: app-settings
    # Or specific keys:
    env:
    - name: DATABASE_HOST
      valueFrom:
        configMapKeyRef:
          name: app-settings
          key: DB_HOST

Mounting ConfigMaps as Volumes

When your app reads config from a file (like nginx.conf), mount the ConfigMap as a volume. Bonus: volume-mounted ConfigMaps auto-update when the ConfigMap changes (within ~60s).

spec:
  containers:
  - name: web
    image: nginx
    volumeMounts:
    - name: config-vol
      mountPath: /etc/nginx/conf.d
      readOnly: true
  volumes:
  - name: config-vol
    configMap:
      name: nginx-conf
      items:            # optional: select specific keys
      - key: nginx.conf
        path: default.conf

Secrets: The Vault Where Sensitive Data Lives

Secrets are structurally similar to ConfigMaps but designed for sensitive data: passwords, tokens, TLS certificates. But here's the uncomfortable truth...

Secret Types & Creation

# Create a generic secret imperatively
kubectl create secret generic db-creds \
  --from-literal=username=admin \
  --from-literal=password=S3cureP@ss!

# Create TLS secret
kubectl create secret tls app-tls \
  --cert=tls.crt --key=tls.key

Consuming Secrets in Pods

spec:
  containers:
  - name: app
    env:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: db-creds
          key: password

spec:
  containers:
  - name: app
    volumeMounts:
    - name: secret-vol
      mountPath: /etc/secrets
      readOnly: true
  volumes:
  - name: secret-vol
    secret:
      secretName: db-creds

Azure Key Vault CSI: Enterprise Secrets Management

Kubernetes Secrets have limitations. For production, you want a dedicated secrets manager with auditing, rotation, and centralized control. Azure Key Vault fills that role.

SecretProviderClass Configuration

apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
  name: azure-kv-secrets
spec:
  provider: azure
  parameters:
    usePodIdentity: "false"
    useVMManagedIdentity: "false"
    clientID: "<workload-identity-client-id>"
    keyvaultName: "my-keyvault"
    tenantId: "<tenant-id>"
    objects: |
      array:
        - |
          objectName: db-password
          objectType: secret
  secretObjects:             # Optional: sync to K8s Secret
  - secretName: db-creds-synced
    type: Opaque
    data:
    - objectName: db-password
      key: password

Resource Requirements: Setting Budgets for Containers

Imagine a shared office with no rules about desk space. One team takes over three floors while another has no room to work. That's what happens in a cluster without resource limits.

Resource Specs & QoS Classes

spec:
  containers:
  - name: api
    image: myapp:v2
    resources:
      requests:
        cpu: "250m"     # 0.25 cores
        memory: "128Mi"
      limits:
        cpu: "500m"     # 0.5 cores
        memory: "256Mi"

LimitRanges & ResourceQuotas

What if developers forget to set resource requests? Cluster admins use LimitRanges and ResourceQuotas as guardrails.

apiVersion: v1
kind: LimitRange
metadata:
  name: default-limits
spec:
  limits:
  - type: Container
    default:
      cpu: "500m"
      memory: "256Mi"
    defaultRequest:
      cpu: "100m"
      memory: "128Mi"

apiVersion: v1
kind: ResourceQuota
metadata:
  name: team-quota
spec:
  hard:
    requests.cpu: "10"
    requests.memory: "20Gi"
    limits.cpu: "20"
    limits.memory: "40Gi"
    pods: "50"

SecurityContext: Running with Least Privilege

By default, containers run as root. That's like giving every employee a master key to every room in the building. SecurityContext lets you lock down exactly what a container can do.

SecurityContext in Practice

apiVersion: v1
kind: Pod
metadata:
  name: secure-app
spec:
  securityContext:         # Pod-level
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  containers:
  - name: app
    image: myapp:v2
    securityContext:       # Container-level (overrides pod)
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop: ["ALL"]
      seccompProfile:
        type: RuntimeDefault

Pod Security Standards: The Three Tiers

Pod Security Standards (PSS) replaced the deprecated PodSecurityPolicy. They define three profiles applied at the namespace level via labels.

Applying Pod Security Standards

Apply standards via namespace labels. Three enforcement modes let you roll out gradually:

# Apply restricted standard to a namespace
kubectl label namespace production \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted

RBAC: The Four Building Blocks

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: dev
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list", "watch"]

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: node-viewer
rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

RoleBinding & ClusterRoleBinding

Roles define permissions. Bindings attach those permissions to users, groups, or service accounts. Think of it as: Role = "what you can do", Binding = "who gets to do it".

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods-dev
  namespace: dev
subjects:
- kind: User
  name: [email protected]
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding
subjects:
- kind: Group
  name: platform-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

RBAC Verbs & Common Patterns

Testing & Debugging RBAC

Before applying RBAC in production, always test. Kubernetes provides kubectl auth can-i to check permissions without trial and error.

# Can I create deployments in the dev namespace?
kubectl auth can-i create deployments --namespace dev
# yes

# Can user jane list pods in production?
kubectl auth can-i list pods --namespace production --as [email protected]
# no

# What can I do in this namespace? (full list)
kubectl auth can-i --list --namespace dev

# Can a service account create secrets?
kubectl auth can-i create secrets \
  --as=system:serviceaccount:dev:my-sa -n dev

Preventing the Disaster: RBAC for Our Junior Dev

Let's go back to our story. Here's how we'd set up RBAC so that the junior developer can work freely in dev but can only view (never delete) in production:

kind: RoleBinding
metadata:
  name: junior-dev-full
  namespace: dev
subjects:
- kind: User
  name: [email protected]
roleRef:
  kind: ClusterRole
  name: edit  # built-in role

kind: RoleBinding
metadata:
  name: junior-dev-readonly
  namespace: production
subjects:
- kind: User
  name: [email protected]
roleRef:
  kind: ClusterRole
  name: view  # built-in role

Service Accounts: Machine Identity in Kubernetes

Users authenticate as humans. But what about your applications? When your pod needs to talk to the Kubernetes API (e.g., to list pods or create jobs), it uses a Service Account — an identity for machines.

# Create a service account
kubectl create serviceaccount my-app-sa -n dev

# Disable auto-mount on a pod
spec:
  serviceAccountName: my-app-sa
  automountServiceAccountToken: false

Binding RBAC to Service Accounts

A real-world scenario: your monitoring app needs to list pods across all namespaces, but should not be able to create or delete anything.

# 1. Create the ServiceAccount
kubectl create serviceaccount monitor-sa -n monitoring

# 2. Create a ClusterRole with read-only pod access
kubectl create clusterrole pod-reader \
  --verb=get,list,watch --resource=pods

# 3. Bind the ClusterRole to the ServiceAccount
kubectl create clusterrolebinding monitor-pods \
  --clusterrole=pod-reader \
  --serviceaccount=monitoring:monitor-sa

# 4. Verify
kubectl auth can-i list pods --all-namespaces \
  --as=system:serviceaccount:monitoring:monitor-sa
# yes

kubectl auth can-i delete pods -n production \
  --as=system:serviceaccount:monitoring:monitor-sa
# no

Azure AD + AKS RBAC Integration

In AKS, you can integrate Microsoft Entra ID (Azure AD) with Kubernetes RBAC for enterprise identity management. Users authenticate with their corporate credentials.

Network Policies: The Firewall for Pods

By default, every pod can talk to every other pod. Network Policies let you restrict traffic — like firewall rules for your cluster network.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes: ["Ingress", "Egress"]
  ingress:
  - from:
    - podSelector:
        matchLabels: { app: frontend }
    ports:
    - port: 8080
  egress:
  - to:
    - podSelector:
        matchLabels: { app: database }
    ports:
    - port: 5432

Admission Controllers & Image Security

Admission controllers are gatekeepers that intercept API requests before they are persisted. They can validate, mutate, or reject requests.

Production Security Checklist

Hands-On Lab: Secure a Namespace

Practice the concepts from this session with this end-to-end exercise:

# Quick start:
kubectl create namespace secure-app
kubectl label namespace secure-app pod-security.kubernetes.io/enforce=restricted
kubectl create configmap app-config --from-literal=DB_HOST=db.svc -n secure-app
kubectl create secret generic db-creds --from-literal=password=secret -n secure-app
kubectl create serviceaccount app-sa -n secure-app