Внутренняя безопасность в Kubernetes
Все знают про аутентификацию, авторизацию и аудит в Kubernetes. Но нередко возникает вопрос: «Как правильно строить аутентификацию?» Дело в том, что тут есть ряд антипаттернов:
Но на практике, чаще всего, у компаний есть каталог пользователя, например, Active Directory, и они хотят связать его с Kubernetes. Есть несколько способов это сделать: 1. Authenticating Proxy. 2. Webhook Token Authentication. 3. OpenID Connect Tokens.
Один из лучших вариантов с точки зрения специалистов из Mail.ru — OpenID Connect Tokens. Наверное, все знают про безопасный протокол аутентификации OAuth 2.0. Так вот, OpenID Connect является его расширением. Вся фишка в том, что вы интегрируете Кубернетес не напрямую с Active Directory, а ставите посредника, для которого настраивается федерация с Active Directory. При этом в AD хранятся пользователи, пароли и группы, а в IAM пароли уже не хранятся, зато хранится гораздо больше другой информации (аудит логов пользователей, сессии и т. п., плюс можно настроить политику паролей или 2-факторную авторизацию). Далее Kubernetes настраивается на доверие с IAM:
Почему OpenID Connect — это круто:
- Он удобен.
- Обеспечивается повышенная безопасность.
- Это больше, чем проверка Username/Password.
- ID-токены OIDS короткоживущие, следовательно, меньше риски, плюс есть Renew tokens.
- Можно настроить 2-Factor Auth: TOTP-токены.
Стоит добавить, что сегодня на рынке много OpenID Connect-провайдеров, как публичных, так и Private.
Также стоит учитывать, что вам придётся по-другому работать с Kubectl и указывать много дополнительных параметров:
В принципе, эта проблема минимизируется путём применения хелперов:
Читайте также: • Безопасность в Kubernetes. Docker Image Security; • Безопасность в Kubernetes: Host Level Security; • Безопасность в Kubernetes: Container Runtime Security; • Сетевая безопасность в Kubernetes.
