Hantera IAM-roller som K8s-resurser

(Naveen M) (10 jul 2020)

Applikationer som används i Kubernetes-kluster på AWS behöver IAM-roller för att hantera och komma åt AWS-resurser. På Intuit har vi 200+ kluster och 8000+ namnområden. Fram till nyligen hanterades IAM-roller separat från Kubernetes-resurser från ett centraliserat program.

Detta fungerade bra men utvecklare var tvungna att uppdatera sina IAM-policyer manuellt innan de distribuerar sin applikation. Manuella ändringar som krävs för IAM-policyuppdateringar skapade en felmarginal där utvecklare ibland glömmer att uppdatera sin IAM-policy medan de marknadsför den till nästa sceneringsmiljö, och detta skapade en frustration för många utvecklare.

Vi använde för att kontrollera vilka behörigheter som ska tillåtas från vår klusterhanteringstjänst men vissa plattformsapplikationer behövde undantag för att tillåta mer tillåtna policyer. Vi började baka undantaget i koden men insåg snart att vi behövde en mer skalbar lösning.

Det var då vi kom med iam-manager. iam-manager är en k8s CRD (Custom Resource Definition) för att hantera AWS IAM-roller som Kubernetes-resurser. Iam-manager är öppen från en del av Keiko-projektet och gör det möjligt för applikationer att på ett säkert och bekvämt sätt skapa och hantera IAM-roller som en del av deras distributionsledning (dvs. kubectl gäller) tillsammans med andra Kubernetes-resurser.

Som med alla funktioner som skapar eller ändrar roller och behörigheter är säkerhet av största vikt. Iam-manager använder AWS IAM Permission Boundary tillsammans med andra skyddsåtgärder för att säkerställa lämpliga nivåer av synlighet och kontroll.

AWS IAM Permission Boundary played en viktig roll när det gäller säkerhet för oss eftersom utan det kan utvecklare inkludera alla IAM-behörigheter i IAMRole-specifikationen och en applikation med en IAM-roll som har ex: * eller ec2: * -behörigheter kan förstöra hela klustret. Vi ville kontrollera vilka behörigheter som kan delegeras till de roller som skapats av IAM Manager, och Permission Boundary är det perfekta valet för oss. AWS IAM Permission Boundary är ett koncept där du kan skapa en gräns med listan över maximalt tillåtna / (eller nekade) IAM-behörigheter som kan nås oavsett vad som anges i en IAM-rollpolicy. Kort sagt kommer de faktiska behörigheterna att vara korsningen av behörigheterna som anges i tillståndsgränsen och IAM-rollpolicyn.

Låt oss ta ett exempel där en IAM-roll har “ AdministratorAccess ” -policy, vilket innebär att den har stort sett all åtkomst men om vi bifogar en tillståndsgräns som har bara s3: Få * -åtkomst (som INTE kan ändras av användaren men bara av klusteradministratören), att IAM-roll endast kan utföra s3: Get * även om rollen har behörigheter som ”administratör”. Med enkla ord används behörighetsgränser för att begränsa behörigheterna som kan delegeras av iam-manager CRD. Kolla in AWS IAM Permission Boundary från aws-dokumentationen för mer info.

Vi har också webbhook för att avvisa IAM-rollskapningar om IAMRole-specifikationen har en policy som inte ingår i vitlistade policyer som vi kan konfigurera via konfigurationskarta. Detta är helt valfritt eftersom AWS IAM Permission Boundary tar hand om överdrivna behörigheter men kan användas för att hålla policyer mycket rena.

Och sist men inte minst behövde vi vara mycket försiktiga med IAM-rollen som tilldelats iam-manager-controller-pod själv och vi utformade noggrant IAM-behörighetspolicy på ett sätt där den bara kan göra begränsade uppgifter. Det vill säga det kan inte skapa någon IAM-roll utan att bifoga en fördefinierad behörighetsgräns, kan bara skapa roller med fördefinierade namn (dvs. k8s- *) och kan inte heller ta bort roller som inte har fördefinierade TAG: er (vi lade till TAG: erna i de roller som bara skapats av iam-manager). Mer information finns i iam-manager IAM-policy .

Så här installerar du och testar iam-manager:

git clone 
[email protected]:keikoproj/iam-manager.git
cd hack#update config map according to your requirements. please refer #
config map for all the configuration options
vim iammanager.keikoproj.io\_iamroles-configmap.yamlexport KUBECONFIG=/Users/myhome/.kube/[email protected]
export AWS\_PROFILE=admin\_123456789012\_account
#./install.sh [cluster\_name] [aws\_region] [aws\_profile]
./install.sh eks-dev2-k8s us-west-2 aws\_profile

Här är ett enkelt exempel:

apiVersion: iammanager.keikoproj.io/v1alpha1
kind: Iamrole
metadata:
name: iam-manager-iamrole
spec:
# Add fields here
PolicyDocument:
Statement:
-
Effect: "Allow"
Action:
- "s3:Get*"
Resource:
- "arn:aws:s3:::intu-oim*"
Sid: "AllowS3Access"
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
-
Effect: "Allow"
Action: "sts:AssumeRole"
Principal:
AWS:
- "arn:aws:iam::XXXXXXXXXXX:role/20190504-k8s-kiam-role"

För att skicka in kubectl applicera -f iam\_role .yaml – ns namespace1

Tillsammans med att skapa en IAM-roll och bibehålla önskat tillstånd hela tiden, stöder den också att skapa roller för IRSA (IAM Role for Service Accounts) genom att lägga till en kommentar
iam.amazonaws.com/irsa-service-account: till IAMs rollspecifikation .

apiVersion: iammanager.keikoproj.io/v1alpha1
kind: Iamrole
metadata:
name: iam-manager-iamrole-irsa
annotations:
iam.amazonaws.com/irsa-service-account: aws-sa
spec:
# Add fields here
PolicyDocument:
Statement:
-
Effect: "Allow"
Action:
- "s3:Get*"
Resource:
- "arn:aws:s3:::intu-oim*"
Sid: "AllowS3Access"

Sammanfattningsvis är att lägga till iam-manager till ett Kubernetes-kluster inte bara en säker och bekväm lösning för AWS IAM-rollhantering i ett kluster utan också tillåter applikationer team för att skapa en IAM-roll som en del av deras distributionsrörledning tillsammans med andra Kubernetes-resurser via GitOps.

För en fullständig lista över funktioner, se avsnittet med funktioner på https://github.com/keikoproj/iam-manager .

Stort tack till (Ed Lee), (Kshama Jain) och andra teammedlemmar för deras värdefulla bidrag till iam-manager.