Metodtips för poddsäkerhet i Azure Kubernetes Service (AKS)

När du utvecklar och kör program i Azure Kubernetes Service (AKS) är säkerheten för dina poddar en viktig faktor. Dina program bör utformas för principen om minsta antal behörigheter som krävs. Att skydda privata data är viktigt för kunderna. Du vill inte att autentiseringsuppgifter som databasanslutningssträngar, nycklar eller hemligheter och certifikat ska exponeras för världen utanför där en angripare kan dra nytta av dessa hemligheter i skadliga syften. Lägg inte till dem i din kod eller bädda in dem i dina containeravbildningar. Den här metoden skulle innebära en risk för exponering och begränsa möjligheten att rotera autentiseringsuppgifterna eftersom containeravbildningarna måste återskapas.

Den här artikeln om metodtips fokuserar på hur du skyddar poddar i AKS. Lär dig att:

Du kan också läsa metodtipsen för klustersäkerhet och för hantering av containeravbildningar.

Skydda poddåtkomst till resurser

Metodvägledning – Definiera kontextinställningar för poddsäkerhet om du vill köra som en annan användare eller grupp och begränsa åtkomsten till de underliggande nodprocesserna och tjänsterna. Tilldela det minsta antal behörigheter som krävs.

För att dina program ska köras korrekt bör poddar köras som en definierad användare eller grupp och inte som rot. Med securityContext för en podd eller container kan du definiera inställningar som runAsUser eller fsGroup för att anta lämpliga behörigheter. Tilldela endast nödvändiga användar- eller gruppbehörigheter och använd inte säkerhetskontexten som ett sätt att anta ytterligare behörigheter. Inställningarna runAsUser, behörighetseskalering och andra Linux-funktioner är endast tillgängliga på Linux-noder och -poddar.

När du kör som en icke-rotanvändare kan containrar inte binda till privilegierade portar under 1024. I det här scenariot kan Kubernetes Services användas för att dölja det faktum att en app körs på en viss port.

En poddsäkerhetskontext kan också definiera ytterligare funktioner eller behörigheter för åtkomst till processer och tjänster. Följande vanliga definitioner för säkerhetskontext kan anges:

• allowPrivilegeEscalation definierar om podden kan anta rotprivilegier. Utforma dina program så att den här inställningen alltid är inställd på false.
• Med Linux-funktioner kan podden komma åt underliggande nodprocesser. Var noga med att tilldela dessa funktioner. Tilldela det minsta antal behörigheter som krävs. Mer information finns i Linux-funktioner.
• SELinux-etiketter är en Linux-kernelsäkerhetsmodul som gör att du kan definiera åtkomstprinciper för tjänster, processer och filsystemåtkomst. Tilldela återigen det minsta antal behörigheter som krävs. Mer information finns i SELinux-alternativ i Kubernetes

I följande exempel anger YAML-manifestet inställningar för säkerhetskontext för att definiera:

• Podden körs som användar-ID 1000 och en del av grupp-ID 2000
• Det går inte att eskalera behörigheter att använda root
• Tillåter Linux-funktioner att komma åt nätverksgränssnitt och värdens realtidsklocka (maskinvara)

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    fsGroup: 2000
  containers:
    - name: security-context-demo
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      securityContext:
        runAsUser: 1000
        allowPrivilegeEscalation: false
        capabilities:
          add: ["NET_ADMIN", "SYS_TIME"]

Ta hjälp av klusteroperatören för att avgöra vilka inställningar för säkerhetskontext du behöver. Försök att utforma dina program för att minimera ytterligare behörigheter och få åtkomst till podden som krävs. Det finns ytterligare säkerhetsfunktioner som begränsar åtkomsten med AppArmor och seccomp (säker databehandling) som kan implementeras av klusteroperatörer. Mer information finns i Skydda containeråtkomst till resurser.

Begränsa exponering av autentiseringsuppgifter

Vägledning om bästa praxis – Definiera inte autentiseringsuppgifter i programkoden. Använd hanterade identiteter för Azure-resurser för att ge podden åtkomst till andra resurser. Ett digitalt valv, till exempel Azure Key Vault, bör också användas för att lagra och hämta digitala nycklar och autentiseringsuppgifter. Podd-hanterade identiteter är endast avsedda att användas med Linux-poddar och containeravbildningar.

Undvik att använda fasta eller delade autentiseringsuppgifter för att begränsa risken för att autentiseringsuppgifter exponeras i programkoden. Autentiseringsuppgifter eller nycklar ska inte inkluderas direkt i koden. Om dessa autentiseringsuppgifter exponeras måste programmet uppdateras och omdistribueras. En bättre metod är att ge poddar sin egen identitet och ett sätt att autentisera sig själva, eller automatiskt hämta autentiseringsuppgifter från ett digitalt valv.

Använda Överordnade projekt för Azure Container Compute

Med följande associerade AKS-projekt med öppen källkod kan du automatiskt autentisera poddar eller begära autentiseringsuppgifter och nycklar från ett digitalt valv. Dessa projekt underhålls av Azure Container Compute Upstream-teamet och ingår i en bredare lista över projekt som är tillgängliga för användning.

• Azure Active Directory Poddidentitet
• Azure Key Vault provider för CSI-drivrutin för Hemlighetslager

Använda podd hanterade identiteter

Med en hanterad identitet för Azure-resurser kan en podd autentisera sig mot Azure-tjänster som stöder det, till exempel Storage eller SQL. Podden tilldelas en Azure-identitet som gör att de kan autentisera Azure Active Directory och ta emot en digital token. Den här digitala token kan visas för andra Azure-tjänster som kontrollerar om podden har behörighet att komma åt tjänsten och utföra nödvändiga åtgärder. Den här metoden innebär till exempel att inga hemligheter krävs för databasanslutningssträngar. Det förenklade arbetsflödet för podd hanterad identitet visas i följande diagram:

Med en hanterad identitet behöver din programkod inte inkludera autentiseringsuppgifter för att få åtkomst till en tjänst, till exempel Azure Storage. När varje podd autentiseras med sin egen identitet kan du granska och granska åtkomsten. Om ditt program ansluter till andra Azure-tjänster använder du hanterade identiteter för att begränsa återanvändning av autentiseringsuppgifter och risk för exponering.

Mer information om poddidentiteter finns i Konfigurera ett AKS-kluster för att använda podd hanterade identiteter och med dina program

Använda Azure Key Vault med CSI-drivrutin för Secrets Store

När du använder poddidentitetsprojektet kan du autentisera mot att stödja Azure-tjänster. För dina egna tjänster eller program utan hanterade identiteter för Azure-resurser kan du fortfarande autentisera med autentiseringsuppgifter eller nycklar. Ett digitalt valv kan användas för att lagra det här hemliga innehållet.

När program behöver autentiseringsuppgifter kommunicerar de med det digitala valvet, hämtar det senaste hemliga innehållet och ansluter sedan till den nödvändiga tjänsten. Azure Key Vault kan vara det här digitala valvet. Det förenklade arbetsflödet för att hämta autentiseringsuppgifter från Azure Key Vault podd-hanterade identiteter visas i följande diagram:

Med Key Vault lagrar och roterar du regelbundet hemligheter, till exempel autentiseringsuppgifter, lagringskontonycklar eller certifikat. Du kan integrera Azure Key Vault med ett AKS-kluster med hjälp Azure Key Vault providern för CSI-drivrutinen för Secrets Store. CSI-drivrutinen För hemlighetslager gör det möjligt för AKS-klustret att hämta hemligt innehåll från Key Vault och på ett säkert sätt endast tillhandahålla dem till den begärande podden. Arbeta med klusteroperatorn för att distribuera CSI-drivrutinen för Secrets Store till AKS-arbetsnoder. Du kan använda en podd-hanterad identitet för att begära åtkomst Key Vault hämta det hemliga innehåll som behövs via CSI-drivrutinen för Hemlighetsarkiv.

Nästa steg

Den här artikeln fokuserar på hur du skyddar dina poddar. Om du vill implementera några av dessa områden kan du läsa följande artiklar:

• Använda hanterade identiteter för Azure-resurser med AKS
• Integrera Azure Key Vault med AKS