kubernetes-external-secrets | Integrate external secret management systems with Kubernetes | Identity Management library
kandi X-RAY | kubernetes-external-secrets Summary
kandi X-RAY | kubernetes-external-secrets Summary
Kubernetes External Secrets allows you to use external secret management systems, like AWS Secrets Manager or HashiCorp Vault, to securely add secrets in Kubernetes. Read more about the design and motivation for Kubernetes External Secrets on the GoDaddy Engineering Blog. The community and maintainers of this project and related Kubernetes secret management projects use the #external-secrets channel on the Kubernetes slack for discussion and brainstorming.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
- creates an array of pending pending events queue
kubernetes-external-secrets Key Features
kubernetes-external-secrets Examples and Code Snippets
Community Discussions
Trending Discussions on kubernetes-external-secrets
QUESTION
ON GCP,I need to use 2 GCP project; One is for web-application, the other is for storing secrets for web-application ( which structure comes from google's repository
As written in README, I'll store secrets using GCP Secret Manager
procedure I'm planningThis project is allocated for GCP Secret Manager for secrets shared by the organization.
- prj-secret : create secrets in secrets-manager
- prj-application : read secret using kubernetes-external-secrets
in prj-application I want to use workload identity , because I don't want to use as serviceaccountkey doc saying
What I didcreate cluser with
-workload-pool=project-id.svc.id.goog
optionhelm install kubernetes-external-secrets
[skip] kubectl create namespace k8s-namespace ( because I install kubernetes-external-secrets on
default
name space)[skip] kubectl create serviceaccount --namespace k8s-namespace ksa-name ( because I use
default
serviceaccount with exist by default when creating GKE)create google-service-account with
module "workload-identity
ANSWER
Answered 2021-Feb-04 at 19:51You have an issue in your role binding I think. When you say this:
kubernetes_serviceaccount called external-secrets-kubernetes-external-secrets was already created when installing kubernetes-external-secrets with helm. and it bind k8s_sa_name &' external-secrets-kubernetes@my-project-id.iam.gserviceaccount.com, which has ["roles/secretmanager.admin","roles/secretmanager.secretAccessor"].
It's unclear.
external-secrets-kubernetes@my-project-id.iam.gserviceaccount.com,
is created on which project? I guess in prj-application, but not clear.
- I take the assumption (with the name and the link with the cluster) that the service account is created in the prj-application. you grant the role
"roles/secretmanager.admin","roles/secretmanager.secretAccessor"
on which resource?
- On the IAM page of the prj-application?
- On the IAM page of the prj-secret?
- On the secretId of the secret in the prj-secret?
If you did the 1st one, it's the wrong binding, the service account can only access to the secret of the prj-application, and not these of prj-secret.
Note, if you only need to access the secret, don't grand the admin role, only the accessor is required.
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install kubernetes-external-secrets
If you don't want to install helm on your cluster and just want to use kubectl to install kubernetes-external-secrets, you could get the helm client cli first and then use the following sample command to generate kubernetes manifests:. The generated kubernetes manifests will be in ./output_dir and can be applied to deploy kubernetes-external-secrets to the cluster.
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page