Crossplane ProviderRevision и автоматическая обработка удостоверений рабочей нагрузки
Существует множество документации о том, как обрабатывать IAM с помощью GCP и Crossplane, с подробной информацией о том, какие именно команды следует запускать, чтобы связать их вместе с идентификацией рабочей нагрузки.
Моя проблема - автоматизация. Я использую terraform, управляемый GHA, для создания кластера Kubernetes вместе с любыми другими ресурсами GCP, которые ему нужны.
По умолчанию Kubernetes SA, модуль провайдера Crossplane запускается с уникальным именем для каждой версии/выпуска каждого провайдера. Как мне сделать автоматизацию, которая обязательно находится за пределами кластера Kubernetes, добавить привязки GCP IAM к SA, созданному в кластере Kubernetes, с уникальным имя? В качестве альтернативы, если я создаю SA kubernetes с известным именем и запускаю модуль провайдера Crossplane, как мне привязать ClusterRole эту SA к уникальному имени ClusterRole, которое также создает поставщик Crossplane? Полагаю, я мог бы просто создать свою собственную ClusterRole и не использовать какой-либо RBAC, создаваемый поставщиками Crossplane GCP, однако это было бы очень утомительно.
Из https://marketplace.upbound.io/providers/upbound/provider-family-gcp/v1.3.0/docs/configuration вот две ключевые команды, которые необходимо выполнить, чтобы разрешить Kubernetes SA выдавать себя за GCP SA с помощью идентификатор рабочей нагрузки.
$ gcloud iam service-accounts add-iam-policy-binding \
${GCP_SERVICE_ACCOUNT}@${PROJECT_ID}.iam.gserviceaccount.com \
--role roles/iam.workloadIdentityUser \
--member "serviceAccount:${PROJECT_ID}.svc.id.goog[upbound-system/${KUBERNETES_SERVICE_ACCOUNT}]" \
--project ${PROJECT_ID}
$ kubectl annotate serviceaccount ${KUBERNETES_SERVICE_ACCOUNT} \
iam.gke.io/gcp-service-account=${GCP_SERVICE_ACCOUNT}@${PROJECT_ID}.iam.gserviceaccount.com \
-n upbound-system
${KUBERNETES_SERVICE_ACCOUNT} либо содержит поле .status.currentRevision установленного в данный момент поставщика, либо является вашим собственным Kubernetes SA с ClusterRoleBinding к ClusterRole, который содержит поле .status.currentRevision установленного в данный момент поставщика.
Ответы 2
Оказывается, я волновалась по пустякам. Crossplane прикроет вашу спину.
С помощью следующих манифестов Crossplane становится владельцем созданного SA, выполняет сложную операцию по привязке SA к ClusterRole, которую он создает для этой конкретной версии (я не знал, что это произойдет автоматически), и запускает модуль как SA.
---
apiVersion: pkg.crossplane.io/v1
kind: Provider
metadata:
name: provider-gcp-network
spec:
package: xpkg.upbound.io/upbound/provider-gcp-network:v1.3.0
runtimeConfigRef:
name: provider-gcp-network
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: provider-gcp-network
---
apiVersion: pkg.crossplane.io/v1beta1
kind: DeploymentRuntimeConfig
metadata:
name: provider-gcp-network
spec:
serviceAccountTemplate:
metadata:
name: provider-gcp-network
---
apiVersion: gcp.upbound.io/v1beta1
kind: ProviderConfig
metadata:
name: default
spec:
projectID: <projectId>
credentials:
source: InjectedIdentity
Используя кластер GKE Autopilot, я могу затем привязать роли GCP непосредственно к Kubernetes SA и создавать с его помощью ресурсы GCP.
principal://iam.googleapis.com/projects/<projectNumber>/locations/global/workloadIdentityPools/<projectId>.svc.id.goog/subject/ns/<kubernetesNamespace/sa/<kubernetesSA>
Я полагаю, что все в документации поставщика-семейства-gcp, касающееся currentRevision, устарело.
Значит это описание https://docs.upbound.io/providers/provider-gcp/authentication/#workload-identity устарело?
Меня интересует поле «runtimeConfigRef» в вашем описании. Я нахожу поле контроллерConfigRef только в файле Provider.pkg.crossplane.io/v1 (https://doc.crds.dev/github.com/crossplane/crossplane/pkg.crossplane.io/Provider/v1@v1. 4.1)
В настоящее время я изо всех сил пытаюсь заставить свои вещи работать с использованием workloadIdenity, но почему-то мои провайдеры не используют сервисную учетную запись, которую я пытаюсь им предоставить.
Ну теперь я исправил проблему. Моя проблема заключалась в том, что в моем кластере, где работает Crossplane, не была включена Федерация идентификации рабочей нагрузки, а также Nodes. После того, как я обновил кластер и узлы. Это сработало, даже немного иначе, чем я думал, мне даже не нужен пул идентификаторов рабочей нагрузки, кажется, он работает благодаря функции GKE-Metadata кластера, если я правильно ее понял. (cloud.google.com/kubernetes-engine/docs/how-to/…)
Версия 1.4.1 очень старая. В настоящее время Crossplane имеет версию v1.16.0 doc.crds.dev/github.com/crossplane/crossplane/pkg.crossplane.io/… имеет
runtimeConfigRef. docs.upbound.io/providers/provider-gcp/authentication/… также на данный момент устарел. Я полагаю, чтоControllerConfigCRD устарел, начиная с Crossplane 1.14. Кроме того, как я уже сказал, это может быть функция GKE Autopilot, но мне вообще не нужна GCP SA, необходимые роли GCP можно привязать непосредственно к Kubernetes SA с помощью ссылкиprincipal://.