Разрешение на идентификацию рабочей нагрузки GKE запрещено
Я пытаюсь использовать предпочтительный метод Google «Идентификация рабочей нагрузки», чтобы мое приложение GKE могло безопасно получать доступ к секретам из Google Secrets.
Я завершил настройку и даже проверил все шаги в разделе «Устранение неполадок» (https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity?hl=sr-ba#troubleshooting), но я В моих журналах по-прежнему появляется следующая ошибка :
Необработанное исключение. Grpc.Core.RpcException:Status(StatusCode=PermissionDenied, Detail="Permission'secretmanager.secrets.list' запрещен для ресурса 'projects / my-project' (или он может не существовать).")
Я решил, что проблема связана с тем, что пул узлов не использует правильную учетную запись службы, поэтому я воссоздал ее, на этот раз указав правильную учетную запись службы.
К служебной учетной записи добавлены следующие роли:
- Облачная служба сборки
- Аккаунт разработчика Kubernetes Engine
- Агент службы реестра контейнеров
- Секретный менеджер секретный аксессуар
- Наблюдатель за секретным менеджером
Соответствующий исходный код пакета, который я использую для аутентификации, выглядит следующим образом:
var data = new Dictionary<string, string>(StringComparer.OrdinalIgnoreCase);
var request = new ListSecretsRequest
{
ParentAsProjectName = ProjectName.FromProject(projectName),
};
var secrets = secretManagerServiceClient.ListSecrets(request);
foreach(var secret in secrets)
{
var value = secretManagerServiceClient.AccessSecretVersion($"{secret.Name}/versions/latest");
string secretVal = this.manager.Load(value.Payload);
string configKey = this.manager.GetKey(secret.SecretName);
data.Add(configKey, secretVal);
}
Data = data;
Ref. https://github.com/jsukhabut/googledotnet
Я пропустил какой-то шаг в процессе?
Есть идеи, почему Google до сих пор говорит: «Разрешение 'secretmanager.secrets.list' запрещено для ресурса 'projects / my-project' (или оно может не существовать)?»
1 ответ
Как и @sethvargo, упомянутый в комментариях, вам необходимо сопоставить учетную запись службы с вашим модулем, поскольку Workload Identity не использует базовый идентификатор узла и вместо этого сопоставляет учетную запись службы Kubernetes с учетной записью службы GCP. В удостоверении рабочей нагрузки все происходит на уровне модуля.
Назначьте учетную запись службы Kubernetes приложению и настройте ее для работы в качестве учетной записи службы Google.
1. Создайте сервисный аккаунт GCP с необходимыми разрешениями.
2. Создайте сервисный аккаунт Kubernetes.
3. Назначьте учетной записи службы Kubernetes разрешение выдавать себя за учетную запись службы GCP.
4.Запустите рабочую нагрузку от имени учетной записи службы Kubernetes.
Надеюсь, вы используете идентификатор проекта вместо имени проекта в проекте или секрете.
Вы не можете обновить сервисную учетную запись уже созданного модуля.
Перейдите по ссылке, чтобы добавить учетную запись службы в модули.