external-secrets | External Secrets Operator reads information | AWS library

by external-secrets Go Version: helm-chart-0.8.3 License: Apache-2.0

X-Ray Key Features Code Snippets Community Discussions(1)Vulnerabilities Install Support

kandi X-RAY | external-secrets Summary

external-secrets is a Go library typically used in Cloud, AWS applications. external-secrets has no bugs, it has no vulnerabilities, it has a Permissive License and it has medium support. You can download it from GitHub.

The External Secrets Operator reads information from a third party service like AWS Secrets Manager and automatically injects the values as Kubernetes Secrets. Multiple people and organizations are joining efforts to create a single External Secrets solution based on existing projects. If you are curious about the origins of this project, check out this issue and this PR.

Support

Quality

Security

License

Reuse

Support

external-secrets has a medium active ecosystem.

It has 2771 star(s) with 501 fork(s). There are 43 watchers for this library.

There were 5 major release(s) in the last 12 months.

There are 107 open issues and 699 have been closed. On average issues are closed in 82 days. There are 17 open pull requests and 0 closed requests.

It has a neutral sentiment in the developer community.

The latest version of external-secrets is helm-chart-0.8.3

Quality

external-secrets has 0 bugs and 0 code smells.

Security

external-secrets has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

external-secrets code analysis shows 0 unresolved vulnerabilities.

There are 0 security hotspots that need review.

License

external-secrets is licensed under the Apache-2.0 License. This license is Permissive.

Permissive licenses have the least restrictions, and you can use them in most projects.

Reuse

external-secrets releases are available to install and integrate.

It has 19780 lines of code, 828 functions and 168 files.

It has medium code complexity. Code complexity directly impacts maintainability of the code.

Top functions reviewed by kandi - BETA

kandi's functional review helps you automatically verify the functionalities of the libraries and avoid rework.
Currently covering the most popular Java, JavaScript and Python libraries. See a Sample of external-secrets

Get all kandi verified functions for this library.

external-secrets Key Features

No Key Features are available at this moment for external-secrets.

external-secrets Examples and Code Snippets

No Code Snippets are available at this moment for external-secrets.

Community Discussions

Trending Discussions on external-secrets

workload identity can work 2 different GCP project?

QUESTION

workload identity can work 2 different GCP project?

Asked 2021-Feb-05 at 03:42

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

This project is allocated for GCP Secret Manager for secrets shared by the organization.

procedure I'm planning

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 did

create cluser with -workload-pool=project-id.svc.id.goog option
helm 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:51

You 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.

Source https://stackoverflow.com/questions/66045160

Community Discussions, Code Snippets contain sources that include Stack Exchange Network

Vulnerabilities

No vulnerabilities reported

Install external-secrets

You can download it from GitHub.

Support

AWS Secrets ManagerAWS Parameter StoreAkeylessHashicorp VaultGoogle Cloud Secrets ManagerAzure Key VaultIBM Cloud Secrets ManagerYandex LockboxGitlab Project VariablesAlibaba Cloud KMS (Docs still missing, PRs welcomed!)Oracle VaultGeneric Webhook

Find more information at: