Kubernetes Security Best Practices 2026

Kubernetes je v roce 2026 de facto standardem pro orchestraci kontejnerů. S rostoucí adopcí ale roste i útočná plocha — a bezpečnostní incidenty v Kubernetes prostředích jsou stále častější. Tento článek přináší ucelený přehled bezpečnostních best practices, které odpovídají aktuálnímu stavu technologií, hrozeb a regulací.

Nejde o základní RBAC tutoriál — zaměřujeme se na pokročilé techniky, které v roce 2026 tvoří rozdíl mezi „máme Kubernetes” a „máme bezpečný Kubernetes”.

1. Supply Chain Security: Zabezpečte to, co nasazujete¶

SBOM jako základ¶

Software Bill of Materials (SBOM) se stal povinností — nejen z pohledu best practices, ale i regulací jako NIS2 a Cyber Resilience Act (CRA). Každý container image by měl mít přiložený SBOM ve formátu SPDX nebo CycloneDX.

# Generování SBOM pomocí Syft
syft packages registry.example.com/app:v2.1.0 -o spdx-json > sbom.json

# Atestace SBOM k image pomocí Cosign
cosign attest --predicate sbom.json \
  --type spdxjson \
  registry.example.com/app:v2.1.0

SLSA Framework Level 3+¶

Supply-chain Levels for Software Artifacts (SLSA) definuje úrovně důvěryhodnosti build procesu. V roce 2026 by produkční workloady měly dosahovat minimálně SLSA Level 3:

• Level 1: Dokumentovaný build proces
• Level 2: Hostovaný build s provenance
• Level 3: Hardened build platforma, nepodvratitelný provenance
• Level 4: Dvou-stranná kontrola, hermetický build

# GitHub Actions s SLSA provenance
jobs:
  build:
    permissions:
      id-token: write
      contents: read
      attestations: write
    steps:
      - uses: actions/attest-build-provenance@v2
        with:
          subject-name: registry.example.com/app
          subject-digest: ${{ steps.build.outputs.digest }}
          push-to-registry: true

Image Signing a Verification¶

Každý image nasazený do clusteru musí být podepsán a ověřen. Cosign od projektu Sigstore je v roce 2026 průmyslový standard:

# Kyverno policy pro ověření podpisu
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: verify-image-signature
spec:
  validationFailureAction: Enforce
  rules:
    - name: verify-cosign
      match:
        any:
          - resources:
              kinds: ["Pod"]
      verifyImages:
        - imageReferences: ["registry.example.com/*"]
          attestors:
            - entries:
                - keyless:
                    subject: "[email protected]"
                    issuer: "https://token.actions.githubusercontent.com"

2. Admission Control: Brána do clusteru¶

Kyverno vs OPA Gatekeeper¶

V roce 2026 existují dva hlavní přístupy k admission control:

Kyverno — nativní Kubernetes policy engine s YAML-based pravidly. Jednodušší adopce, silná integrace s Kubernetes API.

OPA Gatekeeper — obecnější policy engine s jazykem Rego. Flexibilnější, ale strmější learning curve.

Pro většinu organizací doporučujeme Kyverno pro jeho přístupnost a pokročilé funkce jako generování zdrojů a mutace:

# Automatické přidání security context
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: add-default-securitycontext
spec:
  rules:
    - name: add-security-context
      match:
        any:
          - resources:
              kinds: ["Pod"]
      mutate:
        patchStrategicMerge:
          spec:
            containers:
              - (name): "*"
                securityContext:
                  runAsNonRoot: true
                  readOnlyRootFilesystem: true
                  allowPrivilegeEscalation: false
                  capabilities:
                    drop: ["ALL"]
                  seccompProfile:
                    type: RuntimeDefault

Pod Security Standards — Restricted profil¶

Kubernetes Pod Security Standards (PSS) nahradily zastaralé PodSecurityPolicy. V produkci používejte profil restricted:

apiVersion: v1
kind: Namespace
metadata:
  name: production
  labels:
    pod-security.kubernetes.io/enforce: restricted
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/warn: restricted

Restricted profil vyžaduje: - runAsNonRoot: true - Žádné privilegované kontejnery - Omezené capabilities (pouze NET_BIND_SERVICE) - Seccomp profil RuntimeDefault nebo Localhost - Žádné hostPath volumes - Zakázaný privilege escalation

ValidatingAdmissionPolicy — nativní alternativa¶

Od Kubernetes 1.30 je ValidatingAdmissionPolicy (VAP) GA. Nabízí nativní admission control bez externích webhooků pomocí CEL (Common Expression Language):

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: deny-privileged-containers
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  validations:
    - expression: >-
        object.spec.containers.all(c,
          !has(c.securityContext) ||
          !has(c.securityContext.privileged) ||
          c.securityContext.privileged == false)
      message: "Privilegované kontejnery nejsou povoleny"

VAP je lehčí alternativa k webhookům — běží přímo v API serveru, bez síťového volání. Pro jednoduché politiky je ideální volbou.

3. Network Security: Mikrosegmentace a beyond¶

Network Policies — baseline¶

Výchozí chování Kubernetes je „allow all” — každý pod může komunikovat s každým. To je v produkci nepřijatelné:

# Default deny pro namespace
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Ingress
    - Egress

Pak povolte pouze potřebnou komunikaci:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Cilium Network Policies — Layer 7 a DNS¶

Standardní Kubernetes Network Policies pracují na L3/L4. Cilium rozšiřuje možnosti o L7 filtrování, DNS-aware politiky a identity-based security:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: api-l7-policy
spec:
  endpointSelector:
    matchLabels:
      app: api-gateway
  egress:
    - toEndpoints:
        - matchLabels:
            app: user-service
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api/v1/users/.*"
              - method: "POST"
                path: "/api/v1/users"
    - toFQDNs:
        - matchName: "api.external-service.com"
      toPorts:
        - ports:
            - port: "443"
              protocol: TCP

Mutual TLS (mTLS) automaticky¶

Service mesh řešení jako Cilium (s mTLS podporou), Istio nebo Linkerd zajistí automatickou šifrovanou komunikaci mezi pody. V roce 2026 je Cilium preferovanou volbou díky eBPF — bez sidecar proxy, nižší latence, menší resource overhead:

# Cilium mTLS konfigurace
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: require-mtls
spec:
  endpointSelector:
    matchLabels:
      app: payment-service
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: order-service
      authentication:
        mode: required

4. Runtime Security: Detekce v reálném čase¶

Falco — syscall monitoring¶

Falco monitoruje syscally a detekuje podezřelé chování za běhu. V roce 2026 je Falco zralý CNCF graduated projekt:

# Falco pravidlo pro detekci reverse shell
- rule: Reverse Shell
  desc: Detect reverse shell
  condition: >
    spawned_process and
    proc.name in (bash, sh, zsh) and
    fd.type = ipv4 and
    fd.direction = out
  output: >
    Reverse shell detected
    (user=%user.name command=%proc.cmdline
     connection=%fd.name container=%container.name
     image=%container.image.repository)
  priority: CRITICAL
  tags: [network, process, mitre_execution]

# Detekce čtení citlivých souborů
- rule: Read Sensitive Files
  desc: Detect reading of sensitive files
  condition: >
    open_read and
    sensitive_files and
    container and
    not trusted_containers
  output: >
    Sensitive file read in container
    (file=%fd.name container=%container.name
     image=%container.image.repository)
  priority: WARNING

Tetragon — eBPF security observability¶

Cilium Tetragon je novější alternativa k Falco, postavená na eBPF. Nabízí real-time enforcement (nejen detekci) s minimálním overhead:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: block-sensitive-file-access
spec:
  kprobes:
    - call: "security_file_open"
      syscall: false
      args:
        - index: 0
          type: "file"
      selectors:
        - matchArgs:
            - index: 0
              operator: "Prefix"
              values:
                - "/etc/shadow"
                - "/etc/passwd"
                - "/run/secrets/kubernetes.io"
          matchActions:
            - action: Sigkill

Klíčový rozdíl: Falco detekuje a reportuje, Tetragon může aktivně blokovat. Pro kritické workloady doporučujeme kombinaci obou — Tetragon pro enforcement, Falco pro auditní trail.

Audit Logging¶

Kubernetes audit log je zásadní pro forenzní analýzu a compliance:

# audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # Log all requests to secrets
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["secrets"]
  # Log exec into pods
  - level: RequestResponse
    resources:
      - group: ""
        resources: ["pods/exec", "pods/attach"]
  # Log all changes to RBAC
  - level: RequestResponse
    resources:
      - group: "rbac.authorization.k8s.io"
        resources: ["clusterroles", "clusterrolebindings",
                     "roles", "rolebindings"]
  # Metadata for everything else
  - level: Metadata
    omitStages:
      - RequestReceived

Audit logy směrujte do centrálního SIEM systému (Elasticsearch, Splunk, nebo cloudový SIEM) a nastavte alerting na kritické události.

5. Secrets Management¶

Nikdy v Git, nikdy v env proměnných¶

Kubernetes Secrets jsou base64-encoded, ne šifrované. Pro produkci potřebujete:

1. External Secrets Operator (ESO) — synchronizace secrets z externích vaultů:

apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 5m
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: db-credentials
  data:
    - secretKey: username
      remoteRef:
        key: secret/data/production/database
        property: username
    - secretKey: password
      remoteRef:
        key: secret/data/production/database
        property: password

1. Sealed Secrets — šifrované secrets v Gitu:

kubeseal --format yaml < secret.yaml > sealed-secret.yaml
# sealed-secret.yaml je bezpečné commitnout

1. SOPS + Age/KMS — šifrování souborů s klíči spravovanými přes KMS:

sops --encrypt --age age1... secrets.yaml > secrets.enc.yaml

Rotace secrets¶

Automatická rotace je v roce 2026 nutnost. Nastavte TTL na secrets a používejte dynamické credentials kde je to možné (např. Vault database secrets engine):

# Vault dynamic database credentials
resource "vault_database_secret_backend_role" "app" {
  backend = vault_mount.database.path
  name    = "app-role"
  db_name = "postgres"

  creation_statements = [
    "CREATE ROLE \"{{name}}\" WITH LOGIN PASSWORD '{{password}}' VALID UNTIL '{{expiration}}';",
    "GRANT SELECT, INSERT, UPDATE ON ALL TABLES IN SCHEMA public TO \"{{name}}\";"
  ]

  default_ttl = 3600   # 1 hodina
  max_ttl     = 86400  # 24 hodin
}

6. Image Security¶

Minimální base images¶

Používejte distroless nebo scratch images. Čím méně komponent v image, tím menší útočná plocha:

# Multi-stage build s distroless
FROM golang:1.23 AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -o /server

FROM gcr.io/distroless/static-debian12:nonroot
COPY --from=builder /server /server
USER 65534:65534
ENTRYPOINT ["/server"]

Vulnerability scanning v CI/CD¶

Integrujte scanning do pipeline — nikdy nenasazujte image s kritickými CVE:

# GitHub Actions s Trivy
- name: Scan image
  uses: aquasecurity/trivy-action@master
  with:
    image-ref: registry.example.com/app:${{ github.sha }}
    format: sarif
    output: trivy-results.sarif
    severity: CRITICAL,HIGH
    exit-code: 1  # Fail pipeline na critical/high

Admission control pro image quality gates¶

# Kyverno — povolte pouze images ze schváleného registru
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: restrict-image-registries
spec:
  validationFailureAction: Enforce
  rules:
    - name: validate-registries
      match:
        any:
          - resources:
              kinds: ["Pod"]
      validate:
        message: "Images musí pocházet ze schváleného registru"
        pattern:
          spec:
            containers:
              - image: "registry.example.com/*"
            initContainers:
              - image: "registry.example.com/*"

7. RBAC — Least Privilege v praxi¶

Princip nejmenších oprávnění¶

Vytvářejte granulární role místo použití cluster-admin:

# Role pro deployment pipeline
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: deployer
  namespace: production
rules:
  - apiGroups: ["apps"]
    resources: ["deployments"]
    verbs: ["get", "list", "patch", "update"]
  - apiGroups: [""]
    resources: ["configmaps"]
    verbs: ["get", "list", "create", "update"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

Pravidelný audit RBAC¶

Využijte nástroje jako kubectl-who-can a rakkess pro audit oprávnění:

# Kdo může číst secrets?
kubectl who-can get secrets -n production

# Audit všech cluster-admin bindings
kubectl get clusterrolebindings -o json | \
  jq '.items[] | select(.roleRef.name=="cluster-admin") |
  {name: .metadata.name, subjects: .subjects}'

Service Account tokeny — bound a krátkodobé¶

Od Kubernetes 1.24 nejsou automaticky vytvářeny dlouhodobé SA tokeny. Používejte bound service account tokeny s omezenou platností:

apiVersion: v1
kind: Pod
metadata:
  name: app
spec:
  serviceAccountName: app-sa
  containers:
    - name: app
      image: registry.example.com/app:v2
      volumeMounts:
        - mountPath: /var/run/secrets/tokens
          name: app-token
  volumes:
    - name: app-token
      projected:
        sources:
          - serviceAccountToken:
              path: token
              expirationSeconds: 3600  # 1 hodina
              audience: "api.example.com"

8. Cluster Hardening¶

API Server¶

• Zakažte anonymous auth: --anonymous-auth=false
• Povolte audit logging
• Omezte přístup k API serveru na trusted networks
• Používejte OIDC pro autentizaci uživatelů

etcd¶

• Šifrujte data at rest pomocí EncryptionConfiguration
• Používejte mTLS pro komunikaci s API serverem
• Izolujte etcd od worker nodů
• Pravidelné zálohy s šifrováním

# EncryptionConfiguration pro etcd
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
  - resources:
      - secrets
      - configmaps
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: <base64-encoded-key>
      - identity: {}

Node Security¶

• Automatické OS patching (např. Bottlerocket, Flatcar, Talos)
• CIS Kubernetes Benchmark compliance
• Minimální node OS — pouze to, co je potřeba pro kubelet

# Kontrola CIS compliance pomocí kube-bench
kube-bench run --targets node
kube-bench run --targets master

9. Monitoring a Incident Response¶

Security-focused metriky¶

Sledujte metriky relevantní pro bezpečnost:

• Počet failed authentication attempts
• RBAC denied requests (apiserver_authorization_decisions_total{decision="denied"})
• Admission webhook rejects
• Network policy drops
• Anomálie v resource consumption

Incident Response Playbook¶

Připravte runbooky pro běžné scénáře:

1. Kompromitovaný pod — isolace přes network policy, forenzní snapshot, rotace credentials
2. Únik secrets — okamžitá rotace, audit trail analýza, scope assessment
3. Privilegovaný přístup — revokace, RBAC audit, kontrola lateral movement
4. Supply chain útok — identifikace zasažených images, rollback, SBOM analýza

# Emergency network isolation
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: emergency-isolate
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: compromised-app
  policyTypes:
    - Ingress
    - Egress
  # Prázdné ingress/egress = deny all

10. AI-Driven Security — trend 2026¶

V roce 2026 se stále více organizací obrací k AI pro bezpečnostní operace:

• Anomaly detection — ML modely analyzují vzory síťového provozu a syscallů, identifikují odchylky od baseline chování
• Automated triage — AI prioritizuje security alerty a redukuje alert fatigue
• Predictive patching — predikce exploitability CVE na základě kontextu prostředí
• Natural language policies — experimentální nástroje umožňují definovat bezpečnostní politiky přirozeným jazykem

Nástroje jako ARMO Kubescape, Aqua Security a Sysdig integrují AI-driven analýzu do svých platforem. Je to doplněk, ne náhrada — vždy mějte solidní základy (RBAC, network policies, admission control) na místě.

Checklist: Kubernetes Security 2026¶

Než prohlásíte cluster za „produkčně ready”, ověřte:

• [ ] Pod Security Standards — restricted profil na produkčních namespace
• [ ] Network Policies — default deny, explicitní allow
• [ ] RBAC — least privilege, žádný zbytečný cluster-admin
• [ ] Image signing a verification — Cosign + Kyverno/Gatekeeper
• [ ] SBOM generování a atestace
• [ ] Vulnerability scanning v CI/CD s quality gates
• [ ] Secrets v externím vault (ne v Gitu, ne plain v etcd)
• [ ] Runtime security — Falco nebo Tetragon
• [ ] Audit logging do SIEM
• [ ] etcd encryption at rest
• [ ] mTLS mezi službami
• [ ] Incident response playbook
• [ ] Pravidelný CIS benchmark audit

Závěr¶

Kubernetes security není jednorázový úkol — je to kontinuální proces. Technologie se vyvíjejí (eBPF, VAP, AI-driven detekce), útočníci se adaptují, a regulace zpřísňují požadavky.

Klíčem k úspěchu je defense in depth: žádná jednotlivá vrstva zabezpečení nestačí. Kombinujte supply chain security, admission control, network segmentaci, runtime ochranu a monitoring do koherentní strategie.

Začněte tím, co přinese nejvíce hodnoty s nejmenším úsilím — Network Policies a Pod Security Standards. Pak postupně přidávejte vrstvy podle maturity vašeho týmu a kritičnosti workloadů.