# #kubernetes #google-kubernetes-engine #google-secret-manager #workload-identity
Вопрос:
Я пытаюсь использовать предпочтительный метод Google «Идентификация рабочей нагрузки», чтобы мое приложение GKE могло безопасно получать доступ к секретам из секретов Google.
Я завершил настройку и даже проверил все шаги в разделе Устранение неполадок (https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity?hl=sr-ba#troubleshooting) но я все еще получаю следующую ошибку в своих журналах:
Необработанное исключение. Grpc.Core.RpcException: Статус(StatusCode=Разрешен, Подробно=»Разрешение» secretmanager.secrets.list «запрещено для ресурса» проекты/мой проект » (или он может не существовать)».)
Я решил, что проблема связана с тем, что пул узлов не использует правильную учетную запись службы, поэтому я воссоздал его, на этот раз указав правильную учетную запись службы.
В учетную запись службы добавлены следующие роли:
- Облачный Сервис Сборки
- Учетная запись Разработчика движка Kubernetes
- Агент службы реестра контейнеров
- Секретный Менеджер Секретный Доступ
- Просмотр секретного менеджера
Соответствующий исходный код пакета, который я использую для аутентификации, выглядит следующим образом:
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;
Ссылка. https://github.com/jsukhabut/googledotnet
Я упускаю какой-то шаг в этом процессе?
Есть идеи, почему Google все еще говорит «Разрешение» secretmanager.secrets.list «запрещено для ресурсов» проекты/мой проект » (или его может не существовать)?»
Комментарии:
1. Как вы сопоставили эту учетную запись службы со своим модулем? Идентификатор рабочей нагрузки не использует идентификатор базового узла и вместо этого сопоставляет учетную запись службы k8s с учетной записью службы gcp.
2. Я не думаю, что я сопоставил учетную запись службы k8s с модулем; Я только создал ее и аннотировал в соответствии с документацией, удостоверяющей личность рабочей нагрузки GKE. Вы хотите сказать, что мне нужно сопоставить учетную запись службы k8s с модулем, который будет перехвачен, и использовать мою аннотированную учетную запись службы Google? Если да, то как я могу сопоставить свою учетную запись службы k8s с моим модулем или мне следует сопоставить ее с пулом узлов, чтобы новые модули также включали сопоставление?
3. @sethvargo Я нашел это cloud.google.com/kubernetes-engine/docs/how-to/… но я не уверен, как это сделать на уровне пула узлов, чтобы все будущие модули получали эту конфигурацию учетной записи службы. Есть идеи? Может быть, я неправильно понимаю, как это работает.
4. Суть идентификации рабочей нагрузки заключается в том, что вы больше ничего не делаете на уровне пула узлов. Все происходит на уровне отдельных модулей. Вы создаете учетную запись службы GCP с необходимыми разрешениями. Вы создаете учетную запись службы K8S. Вы даете учетной записи службы K8S разрешение на выдачу себя за учетную запись службы GCP. Вы запускаете свою рабочую нагрузку от имени учетной записи службы K8S.
5. @sethvargo Правильно, но разве пул узлов не создает модули — если я создам модуль вручную, используя файл YAML, что произойдет, если модуль будет уничтожен или обновлен? Извините за фундаментальные вопросы — я не уверен, как работает ручное создание модулей в контексте GKE. Не знаете ли вы, как лучше всего добавить файл YAML в систему управления версиями где-нибудь еще? Спасибо за любой совет!
Ответ №1:
Как и @sethvargo, упомянутый в комментариях, вам необходимо сопоставить учетную запись службы с вашим модулем, поскольку идентификатор рабочей нагрузки не использует идентификатор базового узла, а вместо этого сопоставляет учетную запись службы Kubernetes с учетной записью службы GCP. Все происходит на уровне отдельных модулей в идентификаторе рабочей нагрузки.
Назначьте приложению учетную запись службы Kubernetes и настройте ее в качестве учетной записи службы Google.
1.Создайте учетную запись службы GCP с необходимыми разрешениями.
2.Создайте учетную запись службы Kubernetes.
3.Назначьте учетной записи службы Kubernetes разрешение на выдачу себя за учетную запись службы GCP.
4.Запустите рабочую нагрузку от имени учетной записи службы Kubernetes.
Надеюсь, вы используете идентификатор проекта вместо имени проекта в проекте или секрете.
Вы не можете обновить учетную запись службы уже созданного модуля.
Перейдите по ссылке, чтобы добавить учетную запись службы в модули.