k8s (in)security

Задумывались ли вы когда-нибудь как у облачных провайдеров в managed Kubernetes решается к каким облачным сервисам тот или иной Pod имеет доступ, а к каким нет? Если вопрос у вас такой проскакивал, то для вас статья "IAM roles for Kubernetes service accounts - deep dive". В статье все на примере с AWS, но подобное есть уже и у других облачных провайдеров (у российских пока нет):

1) AWS: IRSA (KSA↔️IAM Role) - ServiceAccount annotation eks.amazonaws.com/role-arn
2) Google: Workload Identity (KSA↔️GSA) - ServiceAccount annotation iam.gke.io/gcp-service-account [1]
3) Azure: AAD Pod Identity (KSA↔️AAD) - Workload label aadpodidbinding (Preview статус)

Как вы можете заметить по описанию реализации связей и воплощению они все отличаются от провайдера к провайдеру ...

www.tgoop.com/k8security/462

3.5K viewsD1g1, edited  Dec 7, 2021 at 06:27

Задумывались ли вы когда-нибудь как у облачных провайдеров в managed Kubernetes решается к каким облачным сервисам тот или иной Pod имеет доступ, а к каким нет? Если вопрос у вас такой проскакивал, то для вас статья "IAM roles for Kubernetes service accounts - deep dive". В статье все на примере с AWS, но подобное есть уже и у других облачных провайдеров (у российских пока нет):

1) AWS: IRSA (KSA↔️IAM Role) - ServiceAccount annotation eks.amazonaws.com/role-arn
2) Google: Workload Identity (KSA↔️GSA) - ServiceAccount annotation iam.gke.io/gcp-service-account [1]
3) Azure: AAD Pod Identity (KSA↔️AAD) - Workload label aadpodidbinding (Preview статус)

Как вы можете заметить по описанию реализации связей и воплощению они все отличаются от провайдера к провайдеру ...

BY k8s (in)security