Administrere IAM-roller som K8s ressurser

(Naveen M) (10. juli 2020)

Applikasjoner distribuert i Kubernetes-klynger på AWS trenger IAM-roller for å administrere og få tilgang til AWS-ressurser. Hos Intuit har vi 200+ klynger og 8000+ navnerom. Inntil nylig pleide IAM-roller å administreres atskilt fra Kubernetes-ressurser fra et sentralisert program.

Dette fungerte bra, men utviklere måtte oppdatere IAM-policyene manuelt før de distribuerer applikasjonen. Manuelle endringer som kreves for IAM-policyoppdateringer, skapte en feilmargin der utviklere noen ganger glemmer å oppdatere IAM-policyen mens de promoterer den til neste iscenesettelsesmiljø, og dette skapte en frustrasjon for mange utviklere.

Vi brukte for å kontrollere hvilke tillatelser som skal tillates fra klyngeadministrasjonstjenesten vår, men noen plattformapplikasjoner trengte unntak for å tillate mer tillatelige retningslinjer. Vi begynte å bake unntaket i koden, men skjønte snart at vi trengte en mer skalerbar løsning.

Det var da vi kom opp med iam-manager. iam-manager er en k8s CRD (Custom Resource Definition) for å administrere AWS IAM-roller som Kubernetes-ressurser. Iam-manager er åpen fra en del av Keiko Project og lar applikasjoner trygt og enkelt lage og administrere IAM-roller som en del av distribusjonsrørledningen (dvs. kubectl gjelder) sammen med andre Kubernetes-ressurser.

Som med alle funksjoner som oppretter eller endrer roller og tillatelser, er sikkerhet av største betydning. Iam-manager bruker AWS IAM Permission Boundary sammen med andre garantier for å sikre passende nivåer av synlighet og kontroll.

AWS IAM Permission Boundary played en viktig rolle når det gjelder sikkerhet for oss, uten utviklere kan de inkludere alle IAM-tillatelser i IAMRole-spesifikasjonen og et program med en IAM-rolle som har eks: * eller ec2: * -tillatelser kan ødelegge hele klyngen. Vi ønsket å kontrollere hvilke tillatelser som kan delegeres til rollene opprettet av IAM Manager, og Permission Boundary er det perfekte valget for oss. AWS IAM Permission Boundary er et konsept der du kan opprette en grense med listen over maksimalt tillatte / (eller nektet) IAM-tillatelser som kan nås uavhengig av hva som er spesifisert i en IAM-rollepolicy. Kort sagt vil de faktiske tillatelsene være skjæringspunktet av tillatelsene som er spesifisert i tillatelsesgrensen og IAM-rollepolitikken.

La oss ta et eksempel der en IAM-rolle har « AdministratorAccess » -policy som betyr at den har stort sett all tilgang, men hvis vi legger til en tillatelsesgrense som har bare s3: Få * tilgang (som IKKE kan endres av brukeren, men bare av klyngeadministratoren), at IAM Role bare kan utføre s3: Få * selv om rollen har «Administrator» -tillatelser. Med enkle ord brukes tillatelsesgrenser for å begrense tillatelsene som kan delegeres av iam-manager CRD. Sjekk ut AWS IAM Permission Boundary fra aws-dokumentasjonen for mer info.

Vi har også webhook for å avvise IAM-rolleoppretting hvis IAMRole-spesifikasjonen har en policy som ikke er inkludert i godkjente policyer som vi kan konfigurere gjennom konfigurasjonskart. Dette er totalt valgfritt da AWS IAM Permission Boundary tar seg av overdreven tillatelse, men kan brukes til å holde policyene veldig rene.

Og sist, men ikke minst, trengte vi å være veldig forsiktige med IAM-rollen som ble tildelt selve iam-manager-controller-pod, og vi utformet nøye IAM-tillatelsespolitikk på en måte der den bare kan gjøre begrensede oppgaver. Det vil si at den ikke kan opprette noen IAM-rolle uten å feste en forhåndsdefinert tillatelsesgrense, den kan bare opprette roller med forhåndsdefinerte navn (dvs. k8s- *) og kan heller ikke slette roller som ikke har forhåndsdefinerte TAGer (vi la TAG-ene til rollene som bare ble opprettet av iam-manager). For mer info, se iam-manager IAM-policy .

Slik installerer og prøver 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

Her er et enkelt eksempel:

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"

For å sende inn, kubectl gjelder -f iam\_role .yaml – ns namespace1

Sammen med å opprette en IAM-rolle og opprettholde ønsket tilstand hele tiden, støtter den også å opprette roller for IRSA (IAM Role for Service Accounts) ved å legge til en kommentar
iam.amazonaws.com/irsa-service-account: to IAM Role Spec .

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"

For å oppsummere, å legge til iam-manager til en Kubernetes-klynge, gir ikke bare en trygg og praktisk løsning for AWS IAM-rollestyring i en klynge, men tillater også applikasjoner team for å opprette en IAM-rolle som en del av distribusjonsrørledningen sammen med andre Kubernetes-ressurser via GitOps.

For en komplett liste over funksjoner, vennligst sjekk funksjonsseksjonen på https://github.com/keikoproj/iam-manager .

Også stor takk til (Ed Lee), (Kshama Jain) og andre teammedlemmer for deres verdifulle bidrag til iam-manager.