Сегодня поговорим про 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. Более того, данный инструмент может оказаться удобнее, чем альтернативные методы.