Security

Authentication Methods

• X.509 Certificates: PKI-based client certificates for strong authentication
• Service Accounts: Kubernetes-managed identities for pods and applications
• OpenID Connect: Integration with external identity providers (like OAuth)
• Webhook Token Auth: Custom authentication logic via webhooks
• Static Token File: Simple file-based token authentication (not recommended for production)

Role-Based Access Control (RBAC)

RBAC provides fine-grained access policies for Kubernetes resources. A Role defines permissions within a specific namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]  # "" indicates the core API group
  resources: ["pods"]  # The resource type to control access to
  verbs: ["get", "watch", "list"]  # Allowed operations on the resource

Role Bindings

RoleBindings assign Roles to users, groups, or service accounts within a namespace.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User  # Can be User, Group, or ServiceAccount
  name: jane  # The name of the user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role  # Can be Role or ClusterRole
  name: pod-reader  # Must match the name of the Role
  apiGroup: rbac.authorization.k8s.io

For cluster-wide permissions, use ClusterRoles and ClusterRoleBindings instead.

Pod Security Standards

Pod Security Standards define three different security levels:

1. Privileged: Unrestricted policy with maximum permissions
2. Baseline: Minimally restrictive policy preventing known privilege escalations
3. Restricted: Heavily restricted policy following security best practices

Pod Security Admission

apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Configuration Areas

• Privilege controls: Preventing privilege escalation, root access
• Capability management: Controlling Linux capabilities
• Volume restrictions: Limiting accessible volume types
• Host namespaces: Controlling access to host network/PID/IPC
• User/group controls: Defining which users containers run as
• Seccomp/AppArmor/SELinux: System-level security profiles

Network Policies

Network policies act as firewalls, controlling pod-to-pod and external communications.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-allow
spec:
  podSelector:  # This policy applies to pods with app=api
    matchLabels:
      app: api
  policyTypes:  # Policy controls both incoming and outgoing traffic
  - Ingress
  - Egress
  ingress:  # Incoming traffic rules
  - from:
    - podSelector:  # Allow traffic only from frontend pods
        matchLabels:
          role: frontend
    - namespaceSelector:  # Optional: Allow from specific namespaces
        matchLabels:
          purpose: production
    ports:  # Restrict to specific port
    - protocol: TCP
      port: 8080
  egress:  # Optional: Control outgoing traffic
  - to:
    - podSelector:
        matchLabels:
          app: database
    ports:
    - protocol: TCP
      port: 5432

TLS Configuration

• Certificate management: Securely managing and rotating TLS certificates
• Ingress TLS: Encrypting external traffic to applications
• API server security: Secure communication with the Kubernetes API
• etcd encryption: Protecting sensitive data in the cluster's datastore
• mTLS with service mesh: Mutual TLS authentication between services

Control Plane Security

• API server security: Restrict access with proper authentication, RBAC, and admission controllers
• etcd encryption: Enable encryption at rest for sensitive data in etcd
• Controller manager: Configure controllers securely with appropriate permissions
• Scheduler security: Protect the scheduler from unauthorized access and manipulation
• Communication security: Encrypt all control plane communications with TLS

Node Security

• Kubelet configuration: Secure kubelet authentication, authorization, and anonymous access
• Container runtime: Use secure container runtime configurations (e.g., gVisor, kata containers)
• Node access control: Minimize SSH access, use bastion hosts, implement proper user management
• System hardening: Follow CIS benchmarks for OS hardening, reduce attack surface
• Node isolation: Implement proper network segmentation for node-to-node communication

Container Security

• Image scanning: Continuously scan for vulnerabilities in container images
• Runtime security: Implement runtime security controls (seccomp, AppArmor, SELinux)
• Resource isolation: Set proper resource limits and requests to prevent DoS
• Vulnerability management: Process for tracking and remediating CVEs
• Build security: Secure CI/CD pipelines, sign images, use minimal base images

Tools and Practices

• Security scanners: Regular scanning of images and infrastructure (Trivy, Clair, Anchore)
• Log analysis: Centralized logging with anomaly detection (ELK, Splunk, Datadog)
• Intrusion detection: Runtime security monitoring (Falco, Sysdig Secure, Aqua)
• Vulnerability scanning: Continuous vulnerability assessment (Nessus, Qualys, OpenVAS)
• Compliance monitoring: Automated compliance checking (Kube-bench, OPA Gatekeeper)
• Admission controllers: Policy enforcement at admission time (PodSecurityPolicy, OPA)
• Runtime protection: Detecting and preventing suspicious behaviors

Response Plan

• Incident detection: Automated alerting based on security events and anomalies
• Response procedures: Documented steps for handling different types of security incidents
  • Container compromise
  • Unauthorized access
  • Data exposure
  • Denial of service
• Recovery process: Methods for secure recovery after an incident
  • Isolation procedures
  • Evidence collection
  • Clean-up and restoration
• Documentation: Thorough documentation of incidents, responses, and lessons learned
• Team responsibilities: Clear roles and responsibilities during security incidents
  • Incident commander
  • Technical lead
  • Communications lead
  • Executive sponsor