Säkerhetsalfabetet i Kubernetes: autentisering, auktorisering, granskning

Så småningom uppstår säkerhetsfrågor i drift av alla system: att säkerställa autentisering, rättighetsdelning, granskning och andra uppgifter. För Kubernetes har det redan skapats många lösningar, som gör det möjligt att uppnå compliance med standarderna även i mycket krävande miljöer... Detta material är ägnat åt grundläggande aspekter av säkerhet som realiserats inom ramen för de inbyggda mekanismerna i K8s. Främst kommer det vara användbart för dem som börjar bekanta sig med Kubernetes, - som en utgångspunkt för att studera frågor relaterade till säkerhet.

Autentisering

I Kubernetes finns det två typer av användare:

• Servicekonton – konton som hanteras av Kubernetes API;
• Användare – "normala" användare, som hanteras av externa, oberoende tjänster.

Den viktigaste skillnaden mellan dessa typer är att det finns speciella objekt i Kubernetes API för Servicekonton (de kallas just ServiceAccounts), som är kopplade till ett namnrymd och en uppsättning autentiseringsdata som lagras i klustret i objekt av typen Secrets. Sådana användare (Service Accounts) är huvudsakligen avsedda för att hantera åtkomsträttigheter till Kubernetes API för processer som körs i Kubernetes-klustret.

Vanliga Användare har däremot inga poster i Kubernetes API: hantering av dem måste göras av externa mekanismer. De är avsedda för människor eller processer som lever utanför klustret.

Varje begäran till API:t är kopplad antingen till ett Service Account, eller till en Användare, eller betraktas som anonym.

Användarens autentiseringsuppgifter inkluderar:

• Användarnamn – användarnamn (beroende av versaler!);
• UID – en maskinläsbar identitetssträng som "är mer konsekvent och unik än användarnamnet";
• Grupper – lista över grupper som användaren tillhör;
• Extra – ytterligare fält som kan användas av auktoriseringmekanismen.

Kubernetes kan använda många olika autentiseringsmekanismer: X509-certifikat, Bearer-token, autentiserande proxy, HTTP Basic Auth. Genom dessa mekanismer kan många auktoriseringsscheman implementeras: från en statisk fil med lösenord till OpenID OAuth2.

Dessutom tillåts användning av flera auktoriseringsscheman samtidigt. Som standard används följande i klustret:

• servicekontots token – för Service Accounts;
• X509 — för användare.

Frågan om hantering av ServiceAccounts faller utanför denna artikel, och för dem som vill lära sig mer rekommenderar jag att börja med sidan med den officiella dokumentationen. Vi ska istället titta närmare på frågan om X509-certifikat.

Certifikat för användare (X.509)

Det klassiska sättet att hantera certifikat innebär:

• generering av en nyckel:

  mkdir -p ~/mynewuser/.certs/
  openssl genrsa -out ~/.certs/mynewuser.key 2048

• generering av en certifikatförfrågan:

  openssl req -new -key ~/mynewuser/.certs/mynewuser.key -out ~/mynewuser/.certs/mynewuser.csr -subj "/CN=mynewuser/O=company"

• behandling av certifikatförfrågan med hjälp av CA-nycklarna i Kubernetes-klustret, erhållande av användarcertifikatet (för att få certifikatet måste ett konto med tillgång till nyckeln för certifikatmyndigheten i Kubernetes-klustret användas, som som standard ligger i /etc/kubernetes/pki/ca.key):

  openssl x509 -req -in ~/mynewuser/.certs/mynewuser.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out ~/mynewuser/.certs/mynewuser.crt -days 500

• skapa en konfigurationsfil:
  • beskrivning av klustret (ange adress och plats för CA-certifikatfilen för den specifika installationen av klustret):

    kubectl config set-cluster kubernetes --certificate-authority=/etc/kubernetes/pki/ca.crt --server=https://192.168.100.200:6443

  • eller — som inteett rekommenderat alternativ — det går att hoppa över rötternas certifikat (då kommer kubectl inte att kontrollera api-serverns giltighet i klustret):

    kubectl config set-cluster kubernetes --insecure-skip-tls-verify=true --server=https://192.168.100.200:6443

  • lägga till användaren i konfigurationsfilen:

    kubectl config set-credentials mynewuser --client-certificate=.certs/mynewuser.crt --client-key=.certs/mynewuser.key

  • lägga till kontext:

    kubectl config set-context mynewuser-context --cluster=kubernetes --namespace=target-namespace --user=mynewuser

  • ange standardkontext:

    kubectl config use-context mynewuser-context

Efter de ovan nämnda åtgärderna kommer filen .kube/config att skapa en konfiguration av följande typ:

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /etc/kubernetes/pki/ca.crt
    server: https://192.168.100.200:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: target-namespace
    user: mynewuser
  name: mynewuser-context
current-context: mynewuser-context
kind: Config
preferences: {}
users:
- name: mynewuser
  user:
    client-certificate: /home/mynewuser/.certs/mynewuser.crt
    client-key: /home/mynewuser/.certs/mynewuser.key

För att underlätta överföringen av konfigurationen mellan konton och servrar är det användbart att redigera värdena för följande nycklar:

• certificate-authority
• client-certificate
• client-key

För detta kan man koda de angivna filerna med hjälp av base64 och skriva in dem i konfigurationen, genom att lägga till suffixet -data, dvs. få certificate-authority-data och så vidare.

Certifikat med kubeadm

Med releasen Kubernetes 1.15 att arbete med certifikat har blivit mycket enklare tack vare alpha-versionen av dess stöd i verktyget kubeadm. Här är ett exempel på hur konfigurationen för användarens nycklar kan se ut:

kubeadm alpha kubeconfig user --client-name=mynewuser --apiserver-advertise-address 192.168.100.200

NB: Den nödvändiga advertise address kan ses i konfigurationen av api-servern, som som standard ligger i /etc/kubernetes/manifests/kube-apiserver.yaml.

Den resulterande konfigurationen kommer att skrivas ut i stdout. Den måste sparas i ~/.kube/config användarkontot eller i en fil som anges i miljövariabeln KUBECONFIG.

Gräva djupare

För den som vill gå djupare in i de beskrivna frågorna:

• en separat artikel om arbete med certifikat i den officiella Kubernetes-dokumentationen;
• en bra artikel från Bitnami, som tar upp certifikatfrågan ur praktisk synvinkel.
• allmän dokumentation om autentisering i Kubernetes.

Behörighet

Det autentiserade kontot har som standard inga rättigheter att agera i klustret. För att ge behörigheter i Kubernetes finns en behörighetsmekanism.

Före version 1.6 användes en behörighetstyp som kallas ABAC (Attributbaserad åtkomstkontroll). Mer information om detta finns i den officiella dokumentationen. Denna metod anses idag vara föråldrad (legacy), men du kan fortfarande använda den samtidigt med andra behörighetstyper.

Det aktuella (och mer flexibla) sättet att dela upp åtkomsträttigheter till klustret kallas RBAC (Rollbaserad åtkomstkontroll). Den introducerades som stabil i version Kubernetes 1.8. RBAC implementerar en rättighetsmodell där allt som inte är uttryckligen tillåtet är förbjudet.
För att aktivera RBAC, måste du köra Kubernetes api-server med parametern --authorization-mode=RBAC. Parametrarna ställs in i manifestet för konfigureringen av api-servern, som som standard ligger på vägen /etc/kubernetes/manifests/kube-apiserver.yaml, i avsnittet command. Men i alla fall är RBAC som standard redan aktiverat, så det är förmodligen inget att oroa sig för: detta kan bekräftas av värdet authorization-mode (i den redan nämnda kube-apiserver.yaml). För övrigt kan det finnas andra typer av behörighet bland dess värden (node, webhook, always allow), men vi lämnar deras behandling utanför detta material.

För övrigt har vi redan publicerat artikeln en tillräckligt detaljerad beskrivning av principerna och särskiljningarna av arbetet med RBAC, så jag begränsar mig här till en kort uppräkning av grunderna och exempel.

För hantering av åtkomst i Kubernetes via RBAC används följande API-entiteter:

• Roll och ClusterRole — roller som används för att beskriva åtkomsträttigheter:
• Roll möjliggör att beskriva rättigheter inom ett namnrymde;
• ClusterRole — inom klustret, inklusive kluster-specifika objekt som noder, non-resources urls (dvs. inte relaterade till Kubernetes-resurser — till exempel, /version, /logs, /api*);
• RoleBinding och ClusterRoleBinding — används för att binda Roll och ClusterRole till en användare, användargrupp eller ServiceAccount.

Entiteterna Role och RoleBinding är begränsade till namnrymden, dvs. de måste vara inom samma namnrymd. Men RoleBinding kan referera till ClusterRole, vilket möjliggör skapandet av en uppsättning typiska behörigheter och hantering av åtkomst med hjälp av dessa.

Roller beskriver behörigheter med hjälp av uppsättningar regler som innehåller:

• API-grupper — se den officiella dokumentationen om apiGroups och kommandot kubectl api-resources;
• resurser (resources: pod, namnrymd, deployment och liknande);
• verb (verbs: set, update och liknande).
• resursnamn (resourceNames) — för fall när det är nödvändigt att ge åtkomst till en specifik resurs, inte alla resurser av den typen.

En mer detaljerad genomgång av autentisering i Kubernetes kan hittas på sidan den officiella dokumentationen. Istället för detta (eller snarare — som tillägg till detta) får ni exempel som illustrerar dess funktion.

Exempel på RBAC-enheter

En enkel Roll, som tillåter att få lista och status på poddar och övervaka dem i namnrymden target-namespace:

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

Exempel ClusterRole, vilket möjliggör att få lista och status på poddar och övervaka dem i hela klustret:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # avsnittet "namespace" finns inte, eftersom ClusterRole används för hela klustret
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Exempel RoleBinding, vilket ger användaren mynewuser "läsa" poddar i namnrymden my-namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: target-namespace
subjects:
- kind: User
  name: mynewuser # användarnamn är skiftlägeskänsligt!
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role # här bör vara “Role” eller “ClusterRole”
  name: pod-reader # namnet på Role som finns i samma namnrymd,
                   # eller namnet på ClusterRole vars användning
                   # vi vill tillåta för användaren
  apiGroup: rbac.authorization.k8s.io

Händelsegranskning

Schematisk kan Kubernetes-arkitekturen representeras som följande:

Den centrala komponenten i Kubernetes som är ansvarig för att bearbeta förfrågningar är api-server. Alla operationer med klustret går genom det. Mer om dessa interna mekanismer kan läsas i artikeln "Vad händer i Kubernetes när man kör kubectl run?».

Systemaudit är en intressant funktion i Kubernetes som som standard är avstängd. Den gör det möjligt att logga alla anrop till Kubernetes API. Som man lätt kan förstå, görs alla åtgärder relaterade till kontroll och förändring av klustrets tillstånd via detta API. En bra beskrivning av dess möjligheter kan (som vanligt) hittas i den officiella dokumentationen K8s. Nedan kommer jag att försöka förklara ämnet på ett enklare sätt.

Så, För att aktivera audit, måste vi överföra tre obligatoriska parametrar till containern i api-servern, mer om dem finns nedan:

• --audit-policy-file=/etc/kubernetes/policies/audit-policy.yaml
• --audit-log-path=/var/log/kube-audit/audit.log
• --audit-log-format=json

Förutom dessa tre nödvändiga parametrar finns det många ytterligare inställningar relaterade till audit: från loggrotation till beskrivningar av webhook. Här är ett exempel på loggrotationsparametrar:

• --audit-log-maxbackup=10
• --audit-log-maxsize=100
• --audit-log-maxage=7

Men vi kommer inte att gå djupare in på dem — alla detaljer kan hittas i dokumentationen för kube-apiserver.

Som redan nämnts ställs alla parametrar in i manifestet med konfigurationen av api-servern (som standard /etc/kubernetes/manifests/kube-apiserver.yaml), i sektionen command. Låt oss återvända till de tre obligatoriska parametrarna och gå igenom dem:

1. audit-policy-file — sökväg till YAML-filen med beskrivningen av audit policyn. Vi kommer tillbaka till dess innehåll, men låt mig påpeka att filen måste vara läsbar för processen api-server. Därför måste den monteras inuti containern, vilket kan göras genom att lägga till följande kod i de relevanta sektionerna av konfigurationsfilen:

     volumeMounts:
       - mountPath: /etc/kubernetes/policies
         name: policies
         readOnly: true
     volumes:
     - hostPath:
         path: /etc/kubernetes/policies
         type: DirectoryOrCreate
       name: policies

2. audit-log-path — sökväg till loggfilen. Sökvägen måste också vara tillgänglig för processen api-server, så vi beskriver också dess montering:

     volumeMounts:
       - mountPath: /var/log/kube-audit
         name: logs
         readOnly: false
     volumes:
     - hostPath:
         path: /var/log/kube-audit
         type: DirectoryOrCreate
       name: logs

3. audit-log-format — formatet för auditloggen. Som standard är detta json, men det finns också ett föråldrat textformat (legacy).

Auditpolicy

Nu om den nämnda filen med beskrivningen av loggningspolicyn. Det första begreppet audit policy — är detta nivå, loggningsnivå. Dessa kan vara följande:

• None — ingen loggning;
• Metadata — logga metadata om begäran: användare, tid för begäran, målinnehållet (pod, namespace osv.), typ av åtgärd (verb) osv.;
• Begäran — logga metadata och kropp av begäran;
• BegäranSvar — logga metadata, kropp av begäran och kropp av svar.

De senaste två nivåerna (Begäran och BegäranSvar) loggar inte begärningar som inte har riktat sig mot resurser (begärningar till så kallade non-resources urls).

Dessutom passerar alla begärningar genom flera stadier:

• BegäranMottagen — steg där begäran har mottagits av hanteraren och inte har vidarebefordrats i kedjan av hanterare;
• SvarStartad — svaret har skickats, men före kroppens svar. Genereras för långa begärningar (till exempel, övervaka);
• SvarFullständig — svarskroppen har skickats, mer information kommer inte att skickas;
• Panik — händelser genereras när ett avvikande tillstånd upptäckts.

För att hoppa över vissa stadier kan man använda hoppaÖverStadier.

I policydokumentet kan vi beskriva flera sektioner med olika loggnivåer. Den första lämpliga regeln som hittas i beskrivningen av policyn kommer att tillämpas.

Demon kubelet övervakar ändringar i manifestet med konfigurationen för api-servern och när sådana upptäckts, startar den om containern med api-servern. Men det finns en viktig detalj: ändringar i policyn kommer att ignoreras av dem.Efter att ha gjort ändringar i policydokumentet krävs det att man startar om api-servern manuellt. Eftersom api-servern har startats som statisk pod, kommandot kubectl ta bort kommer inte att leda till att den startas om. Man måste manuellt göra docker stop på kube-master där revisionspolicyn har ändrats:

docker stop $(docker ps | grep k8s_kube-apiserver | awk '{print $1}')

Vid aktivering av revisionen är det viktigt att komma ihåg att belastningen på kube-apiservern ökar.. Företrädesvis ökar minnesanvändningen för att lagra begärningskontext. Loggningen börjar först efter att svaret har skickats. Belastningen beror också på konfigurationen av revisionspolicyn.

Exempel på policyer

Låt oss gå igenom strukturen av policydokumenten med exempel.

Här är en enkel fil policy, för att logga allt på nivå Metadata:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata

I policyn kan man ange en lista med användare (Användare och ServiceAccounts) och användargrupper. Till exempel, så här kommer vi att ignorera systemanvändare, men logga allt annat på nivå Begäran:

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  - level: None
    userGroups:
      - "system:serviceaccounts"
      - "system:nodes"
    users:
      - "system:anonymous"
      - "system:apiserver"
      - "system:kube-controller-manager"
      - "system:kube-scheduler"
  - level: Request

Det finns också möjlighet att beskriva mål:

• namnrymder (namnrymder);
• verb (verbs: hämta, update, ta bort och andra);
• resurser (resources, nämligen: pod, configmaps och så vidare) och resursgrupper (apiGroups).

Observera! Resurser och resursgrupper (API-grupper, dvs. apiGroups), samt deras versioner som är installerade i klustret, kan hämtas med kommandona:

kubectl api-resources
kubectl api-versions

Följande audit policy ges som en demonstration av bästa praxis i dokumentationen från Alibaba Cloud:

apiVersion: audit.k8s.io/v1beta1
kind: Policy
# Utesluta loggning av steget RequestReceived
omitStages:
  - "RequestReceived"
rules:
  # Utesluta loggning av händelser som bedöms som obetydliga och ofarliga:
  - level: None
    users: ["system:kube-proxy"]
    verbs: ["watch"]
    resources:
      - group: "" # detta är api-gruppen med ett tomt namn, som hör till
                  # de grundläggande resurserna i Kubernetes, kallade “core”
        resources: ["endpoints", "services"]
  - level: None
    users: ["system:unsecured"]
    namespaces: ["kube-system"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["configmaps"]
  - level: None
    users: ["kubelet"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    userGroups: ["system:nodes"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["nodes"]
  - level: None
    users:
      - system:kube-controller-manager
      - system:kube-scheduler
      - system:serviceaccount:kube-system:endpoint-controller
    verbs: ["get", "update"]
    namespaces: ["kube-system"]
    resources:
      - group: "" # core
        resources: ["endpoints"]
  - level: None
    users: ["system:apiserver"]
    verbs: ["get"]
    resources:
      - group: "" # core
        resources: ["namespaces"]
  # Utesluta loggning av anrop till read-only URLs:
  - level: None
    nonResourceURLs:
      - /healthz*
      - /version
      - /swagger*
  # Utesluta loggning av meddelanden som rör resurstypen “events”:
  - level: None
    resources:
      - group: "" # core
        resources: ["events"]
  # Resurser av typ Secret, ConfigMap och TokenReview kan innehålla hemliga data,
  # så vi loggar endast metadata relaterade till dessa begärningar
  - level: Metadata
    resources:
      - group: "" # core
        resources: ["secrets", "configmaps"]
      - group: authentication.k8s.io
        resources: ["tokenreviews"]
  # Åtgärder av typen get, list och watch kan vara resurskrävande; vi loggar inte dem
  - level: Request
    verbs: ["get", "list", "watch"]
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Standard loggnivå för standard API-resurser
  - level: RequestResponse
    resources:
      - group: "" # core
      - group: "admissionregistration.k8s.io"
      - group: "apps"
      - group: "authentication.k8s.io"
      - group: "authorization.k8s.io"
      - group: "autoscaling"
      - group: "batch"
      - group: "certificates.k8s.io"
      - group: "extensions"
      - group: "networking.k8s.io"
      - group: "policy"
      - group: "rbac.authorization.k8s.io"
      - group: "settings.k8s.io"
      - group: "storage.k8s.io"
  # Standard loggnivå för alla andra förfrågningar
  - level: Metadata

Ett annat bra exempel på audit policy — profilen som används i GCE.

För att snabbt kunna reagera på audit-händelser finns möjligheten att beskriva en webhook. Denna fråga beskrivs i den officiella dokumentationen, jag kommer att lämna det utanför denna artikel.

Sammanfattning

Artikeln ger en översikt över säkerhetsmekanismerna i Kubernetes-kluster som möjliggör skapandet av personliga användarkonton, separation av deras rättigheter och registrering av deras aktiviteter. Jag hoppas att det kommer att vara till hjälp för dem som har stött på sådana frågor i teorin eller redan i praktiken. Jag rekommenderar också att läsa igenom listan över andra resurser om säkerhet i Kubernetes som anges i "P.S.", — kanske finner du i dem de nödvändiga detaljerna om aktuella problem.

P.S.

Läs även i vår blogg:

• «33+ verktyg för Kubernetes-säkerhet»;
• «Introduktion till Kubernetes nätverkspolicyer för säkerhetsspecialister»;
• «Förstå RBAC i Kubernetes»;
• «9 bästa praxis för att säkerställa säkerheten i Kubernetes»;
• «11 sätt att (inte) bli offer för hackning i Kubernetes».

Källa: habr.com