tgoop.com/k8security/259
Last Update:
Сегодня поговорим про Workload Identity в GKEОчень часто в managed Kubernetes нам приходится работать с managed базами и другими облачными ресурсами. Для аутентификации в них у каждого облака есть IAM и ServiceAccount'ы, которые позволяют гибко настроить доступы. В общем случае чтобы получить токен от ServiceAccount'а нужно обратится в Metadata API c инстанса, ServiceAccount задается для каждого Compute instance.
Минусы такого подхода для Kubernetes:
- из-за того, что на одной ноде могут быть разные поды и нагрузки, приходится выдавать больше привилегий ServiceAccount'у
- из-за миграций нагрузок по нодам, приходится выдавать всем нодам одинаковый ServiceAccountВ итоге данное решение не очень гибко и противоречит least privilege principle.
Альтернативно, можно хранить ключи от ServiceAccount'ов в Kubernetes Secrets, но тогда необходимо самому задумываться о ротации ключей.
Тут нам на помощь приходит Workload IdentityЭта фича позволяет Kubernetes ServiceAccount'ам аутентифицироваться за Cloud ServiceAccount. Таким образом, пропадает зависимость от Compute ServiceAccount, и решаются вышеописанные проблемы.
В GKE Autopilot (о котором мы писали ранее) эта опция включена по дефолту. Технически это реализовано через перехват запросов к Metadata API, в кластер добавляется DaemonSet с соответствующим функционалом.
Вердикт - must have для тех, кто работает с облаком из GKE. Более того, данный инструмент может оказаться удобнее, чем альтернативные методы.
BY k8s (in)security
Share with your friend now:
tgoop.com/k8security/259