Имеются у нас Github runners, которые запущены в виде подов в Kubernetes-кластере, см. Github: обзор Github Actions и деплой с ArgoCD.

На них выполняеттся сборка docker-образов и их пуш в Docker Hub, а затем деплой приложения с Helm или ArgoCD.

При первом запуске helm install в поде получаем ошибку «x509: certificate signed by unknown authority«:

А без указания API-сервера — ошибка прав доступа:

Собственно, проблема ясна: Helm в поде пытается достучаться к API-серверу, используя default ServiceAccount, который был создан при деплое Github runner.

Проверка доступа ServiceAccount

Как уже писалось в Kubernetes: ServiceAccounts, JWT-токены, аутентификация и RBAC-авторизация, для аутентификации на API-сервере нам нужны токен и ключ Certificate Authority.

Подключаемся в под:

Создаём переменные:

И пробуем получить доступ к API сейчас:

Аналогичную ошибку увидим, если запустим kubectl get pod сейчас из этого пода:

Хорошо, и что нам делать?

Создание Kubernetes ServiceAccount для Kubernetes Pod

Собственно, вместо того, что бы монтировать к создаваемым подам дефолтный ServiceAccount с его токеном — нам надо создать свой, которому мы дадим доступ к ресурсам API-сервера через Kubernetes RBAC Role и Kubernetes RBAC  RoleBinding.

Создание RBAC Role

Роль можно взять дефолтную, из списка User-facing roles, например cluster-admin:

Или написать свою, с чётким ограничем доступов. К примеру, дадим доступ к verb (действия) get и list на resources pod:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
   name: "github-runner-deployer-role"
rules:
 - apiGroups: [""]
   resources: ["pods"]
   verbs: ["get", "list"]

Создаём эту роль в нужном нам неймспейсе:

Проверяем:

Создание ServiceAccount

Далее, создадим сервис-аккаунт в этом неймспейсе:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: "github-runner-deployer-sa"

Применяем:

Создание RoleBinding

Теперь, надо создать binding — связь между этим ServiceAccount и созданной ранее ролью.

Создаём RoleBinding:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
   name: "github-runner-deployer-rolebinding"
subjects:
 - kind: ServiceAccount
   name: "github-runner-deployer-sa"
   namespace: "dev-1-18-backend-github-runners-helm-ns"
roleRef:
   kind: Role
   name: "github-runner-deployer-role"
   apiGroup: rbac.authorization.k8s.io

Применяем её:

Подключение ServiceAccount к Kubernetes Pod

И последним осталось подключить созданный ServiceAccount к нашим подам.

Можно проверить через создание нового статичного пода, без деплоймента и скейлинга:

apiVersion: v1
kind: Pod
metadata:
  name: "github-runners-deployer-pod"
spec:
  containers:
    - name: "github-runners-deployer"
      image: "nginx"
      ports:
        - name: "web"
          containerPort: 80
          protocol: TCP
  serviceAccountName: "github-runner-deployer-sa"

Создаём под:

Подключаемся в него:

И проверяем доступ к API:

Теперь доступ к get и list подов есть. А вот к Secrets — нет, так как не задано в нашей роли:

Helm ServiceAccount

Вернёмся к Helm и нашим Github Runners.

Собственно, Helm из подов Github runners будет деплоить всё и везде, так что можно выдать ему админ-права на весь кластер, подключив ClusterRole cluster-admin.

Удаляем созданный выше биндинг:

Создаём новый, но теперь с типом ClusterRoleBinding, что бы дать права на все неймспейсы кластера:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
   name: "github-runner-deployer-cluster-rolebinding"
subjects:
 - kind: ServiceAccount
   name: "github-runner-deployer-sa"
   namespace: "dev-1-18-backend-github-runners-helm-ns"
roleRef:
   kind: ClusterRole
   name: "cluster-admin"
   apiGroup: rbac.authorization.k8s.io

Подключаем сервис-аккаунт к этой кластер-роли:

Возвращаемся в под, и пробуем получить доступ к секретам теперь:

Всё — теперь наш Helm получил полный доступ к кластеру.

Осталось обновить Deployment для Github runners, и задать там новый ServiceAccount.

Редактируем его:

Задаём новый SA — указываем serviceAccount:

Ждём, пока поды пересоздадутся (см. Kubernetes: ConfigMap и Secrets — auto-reload данных в подах), подключаемся, и проверяем:

Доступ к другим неймспейсам — ведь мы создавали ClusterRoleBinding, который применяется ко всему кластеру, а не отдельному namespace, как в случае с обычным RoleBinding:

Отлично — в неймспейс istio-system тоже полный доступ есть.

И доступ самого Helm:

Готово.