Как загрузить привилегии RBAC при запуске кластера GKE с помощью Terraform - PullRequest
Новая
       30

Как загрузить привилегии RBAC при запуске кластера GKE с помощью Terraform

0 голосов
/ 06 июля 2018

Я привожу кластер GKE с Terraform, который прекрасно работает. Затем я хочу, чтобы Terraform выполнил некоторые операции уровня Kubernetes на кластере (с использованием провайдера k8s) - ничего особенного, просто установка пары развертываний и т. Д.

У меня проблема с разрешениями. Я бы хотел аккуратный, аккуратный, декларативный способ создать кластер и иметь под рукой набор учетных данных, которые я могу использовать для краткосрочных операций "admin" над ним, включая загрузку других пользователей. Я знаю, как сделать пользователя Google, который запускает TF, администратором кластера (этот вопрос часто возникает), но это не кажется очень хорошим . Что не менее важно, провайдер TF k8s не поддерживает кластеризованное связывание ( Issue , частичный PR ), поэтому вы должны "раскошелиться" с инициатором local-exec для первого запуска gcloud container clusters get-credentials а затем kubectl create clusterrolebinding ....

Точно так же я не хочу устанавливать мастер-пароль, потому что я не хочу работать с базовой аутентификацией HTTP. Самым хорошим вариантом выглядит пара ключ / сертификат, которая возвращается ресурсом TF GKE, но имеет CN "client", и у этого пользователя нет власти. Итак, еще раз, единственный способ его использования - это выполнить оболочку в kubectl, передать ей учетные данные учетной записи службы gcloud и заставить его добавить кластерную привязку для «клиента», и в этот момент я могу также просто сделать все, как учетная запись службы как выше.

Для сравнения, на EKS у пользователя (AWS IAM), который создает кластер, есть cluster-admin из коробки (я предполагаю, что утверждение поставщика AWS authn, что пользователь находится в "system: master").

Мой настоящий вопрос здесь таков: есть ли в Terraform аккуратный, полностью декларативный способ вызвать кластер и иметь (в идеале в качестве вывода) мощный набор учетных данных для использования, а затем отбросить? (да, я знаю, что они останутся в штате)

Мои варианты:

  • «выложить», чтобы дать идентификатор Google TF (в идеале, служебной учетной записи) cluster-admin (который является повышением привилегий, но который работает благодаря плагину gcloud authz)
  • Включите базовую аутентификацию HTTP и задайте пароль учетной записи администратора, а затем используйте псевдонима k8s, который будет выполнять минимальную загрузку другой учетной записи службы.
  • Включите ABAC, чтобы «клиент» (CN выходного ключа / сертификата) имел бесконечную мощность - это то, с чем я сейчас работаю, не судите меня!

И мне не нравится ни один из них!

1 Ответ

0 голосов
/ 17 мая 2019

Я столкнулся с подобной проблемой, которая стала особенно неприятной после недавней проблемы с Kubernetes, которая по умолчанию неожиданно отключила базовую аутентификацию , которая сломала мою ранее работающую конфигурацию Terraform, как только я попытался построить новый кластер из того же конфига.

Наконец-то нашел ответ в этом SO-ответе , в котором рекомендуется метод использования кредитов IAM от Terraform для подключения к кластеру без необходимости «выкладывать». Обратите внимание, что этот метод позволяет кластеризовать разрешения кластера в Terraform без использования внешних инструментов / хаков / и т. Д. И без необходимости включать базовую аутентификацию.

Соответствующая часть этого ответа: 

data "google_client_config" "default" {}

provider "kubernetes" {
  host     = "${google_container_cluster.default.endpoint}"

  token = "${data.google_client_config.default.access_token}"
  cluster_ca_certificate = "${base64decode(google_container_cluster.default.master_auth.0.cluster_ca_certificate)}"

  load_config_file = false
}
...