Сегодня поговорим про Workload Identity в
Минусы такого подхода для
- из-за того, что на одной ноде могут быть разные поды и нагрузки, приходится выдавать больше привилегий
- из-за миграций нагрузок по нодам, приходится выдавать всем нодам одинаковый
Альтернативно, можно хранить ключи от
Тут нам на помощь приходит
В
Вердикт - must have для тех, кто работает с облаком из GKE. Более того, данный инструмент может оказаться удобнее, чем альтернативные методы.
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. Более того, данный инструмент может оказаться удобнее, чем альтернативные методы.