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 bäst för kunderna. Du vill inte ha autentiseringsuppgifter som databas anslutningssträng, nycklar eller hemligheter och certifikat som exponeras för omvärlden där en angripare kan dra nytta av dessa hemligheter i skadliga syften. Lägg inte till dem i koden eller bädda in dem i containeravbildningarna. Den här metoden skulle skapa en risk för exponering och begränsa möjligheten att rotera dessa autentiseringsuppgifter eftersom containeravbildningarna måste återskapas.
Den här artikeln om metodtips fokuserar på hur du skyddar poddar i AKS. Du lär dig att:
- Använda poddsäkerhetskontext för att begränsa åtkomsten till processer och tjänster eller behörighetseskalering
- Autentisera med andra Azure-resurser med microsoft Entra-arbetsbelastnings-ID
- Begära och hämta autentiseringsuppgifter från ett digitalt valv, till exempel Azure Key Vault
Du kan också läsa metodtipsen för klustersäkerhet och hantering av containeravbildningar.
Säker poddåtkomst till resurser
Vägledning för bästa praxis – Definiera kontextinställningar för poddsäkerhet om du vill köras som en annan användare eller grupp och begränsa åtkomsten till de underliggande nodprocesserna och tjänsterna. Tilldela minst antal behörigheter som krävs.
För att dina program ska kunna köras korrekt ska 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 för 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 de privilegierade portarna 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äkerhetskontexter 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 privilegier som behövs. Mer information finns i Linux-funktioner.
- SELinux-etiketter är en Säkerhetsmodul för Linux-kernel som gör att du kan definiera åtkomstprinciper för tjänster, processer och filsystemåtkomst. Tilldela återigen det minsta antal privilegier som behövs. Mer information finns i SELinux-alternativ i Kubernetes
I följande exempel anger YAML-manifestet säkerhetskontextinställningar som ska definieras:
- 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 Att Linux-funktioner får åtkomst till 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"]
Arbeta med klusteroperatorn för att avgöra vilka inställningar för säkerhetskontext som du behöver. Försök att utforma dina program för att minimera ytterligare behörigheter och åtkomst till podden. Det finns ytterligare säkerhetsfunktioner för att begränsa åtkomsten med hjälp av AppArmor och seccomp (säker databehandling) som kan implementeras av klusteroperatorer. Mer information finns i Skydda containeråtkomst till resurser.
Begränsa exponering av autentiseringsuppgifter
Vägledning för bästa praxis – Definiera inte autentiseringsuppgifter i programkoden. Använd hanterade identiteter för Azure-resurser för att låta podden begära å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. Poddhanterade 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 ingå direkt i koden. Om dessa autentiseringsuppgifter exponeras måste programmet uppdateras och distribueras om. En bättre metod är att ge poddar sin egen identitet och sätt att autentisera sig själva, eller automatiskt hämta autentiseringsuppgifter från ett digitalt valv.
Använda ett Microsoft Entra-arbetsbelastnings-ID
En arbetsbelastningsidentitet är en identitet som används av ett program som körs på en podd som kan autentisera sig mot andra Azure-tjänster som stöder den, till exempel Storage eller SQL. Den integreras med de funktioner som är inbyggda i Kubernetes för att federera med externa identitetsprovidrar. I den här säkerhetsmodellen fungerar AKS-klustret som tokenutfärdare, Microsoft Entra ID använder OpenID-Anslut för att identifiera offentliga signeringsnycklar och verifiera tjänstkontotokens äkthet innan du utbyter den mot en Microsoft Entra-token. Din arbetsbelastning kan byta ut en tjänstkontotoken som projiceras till dess volym mot en Microsoft Entra-token med hjälp av Azure Identity-klientbiblioteket med hjälp av Azure SDK eller Microsoft Authentication Library (MSAL).
Mer information om arbetsbelastningsidentiteter finns i Konfigurera ett AKS-kluster för att använda Microsoft Entra-arbetsbelastnings-ID med dina program
Använda Azure Key Vault med CSI-drivrutin för Secrets Store
Med arbetsbelastnings-ID för Microsoft Entra kan du autentisering mot stöd för 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 dessa hemliga innehåll.
När program behöver en autentiseringsuppgift 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 en autentiseringsuppgift från Azure Key Vault med hjälp av poddhanterade identiteter visas i följande diagram:
Med Key Vault lagrar och roterar du regelbundet hemligheter som autentiseringsuppgifter, lagringskontonycklar eller certifikat. Du kan integrera Azure Key Vault med ett AKS-kluster med hjälp av Azure Key Vault-providern för CSI-drivrutinen för Secrets Store. CSI-drivrutinen för Secrets Store gör det möjligt för AKS-klustret att internt 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 ett Microsoft Entra-arbetsbelastnings-ID för att begära åtkomst till Key Vault och hämta det hemliga innehåll som behövs via CSI-drivrutinen för Secrets Store.
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: