aws-secret-sidecar-injector | Kubernetes mutating webhook to fetch secrets | AWS library

by aws-samples Go Version: Current License: Non-SPDX

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

kandi X-RAY | aws-secret-sidecar-injector Summary

aws-secret-sidecar-injector is a Go library typically used in Cloud, AWS, Docker applications. aws-secret-sidecar-injector has no bugs, it has no vulnerabilities and it has low support. However aws-secret-sidecar-injector has a Non-SPDX License. You can download it from GitHub.

The aws-secret-sidecar-injector is a proof-of-concept(PoC) that allows your containerized applications to consume secrets from AWS Secrets Manager. The solution makes use of a Kubernetes dynamic admission controller that injects an init container, aws-secrets-manager-secret-sidecar, upon creation/update of your pod. The init container relies on IRSA to retrieve the secret from AWS Secrets Manager. The Kubernetes dynamic admission controller also creates an in-memory Kubernetes volume (with name secret-vol and emptyDirectory.medium as Memory) associated with the pod to access the secret.

Support

Quality

Security

License

Reuse

Support

aws-secret-sidecar-injector has a low active ecosystem.

It has 94 star(s) with 20 fork(s). There are 17 watchers for this library.

It had no major release in the last 6 months.

There are 4 open issues and 25 have been closed. On average issues are closed in 29 days. There are no pull requests.

It has a neutral sentiment in the developer community.

The latest version of aws-secret-sidecar-injector is current.

Quality

aws-secret-sidecar-injector has 0 bugs and 8 code smells.

Security

aws-secret-sidecar-injector has no vulnerabilities reported, and its dependent libraries have no vulnerabilities reported.

aws-secret-sidecar-injector code analysis shows 0 unresolved vulnerabilities.

There are 4 security hotspots that need review.

License

aws-secret-sidecar-injector has a Non-SPDX License.

Non-SPDX licenses can be open source with a non SPDX compliant license, or non open source licenses, and you need to review them closely before use.

Reuse

aws-secret-sidecar-injector releases are not available. You will need to build from source code and install.

It has 1264 lines of code, 46 functions and 17 files.

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

Top functions reviewed by kandi - BETA

kandi has reviewed aws-secret-sidecar-injector and discovered the below as its top functions. This is intended to give you an instant insight into aws-secret-sidecar-injector implemented functionality, and help decide if they suit your requirements.

Reconcile reconciles SecretsRotationMapping
main is the main entry point for testing
serve serves an admission review request .
applyPodPatch applies the patch to a pod
admitPods returns an admission response for the given pod resource
DenameSpecificAttachment is used to deny a pod attachment
writeOutput writes output to a file
convertAdmissionRequestToV1beta1 converts a v1 . AdmissionRequest to v1beta1 . AdmissionRequest
convertAdmissionRequestToV1 converts a v1beta1 . AdmissionRequest to v1 . AdmissionRequest
mutatePodsSidecar applies the sidecar image to the given sidecar image

Get all kandi verified functions for this library.

aws-secret-sidecar-injector Key Features

No Key Features are available at this moment for aws-secret-sidecar-injector.

aws-secret-sidecar-injector Examples and Code Snippets

No Code Snippets are available at this moment for aws-secret-sidecar-injector.

Community Discussions

Trending Discussions on aws-secret-sidecar-injector

What is the purpose of using a secret injector in k8s instead of coding in my software the stuff to handle my secrets in a vault like google SM

QUESTION

What is the purpose of using a secret injector in k8s instead of coding in my software the stuff to handle my secrets in a vault like google SM

Asked 2021-Aug-04 at 21:39

Ok.. so, we have Google Secret Manager on GCP, AWS Secret Manager in AWS, Key Vault in Azure... and so on.

Those services give you libs so you can code the way your software will access the secrets there. They all look straightforward and sort of easy to implement. Right?

For instance, using Google SM you can like:

...

ANSWER

Answered 2021-Aug-04 at 21:39

There are many possible motivations why you may want to use an abstraction (such as the CSI driver or sidecar injector) over a native integration:

Portability - If you're multi-cloud or multi-target, you may have multiple secret management solutions. Or you might have a different secret manager target for local development versus production. Projecting secrets onto a virtual filesystem or into environment variables provides a "least common denominator" approach that decouples the application from its secrets management provider.
Local development - Similar to the previous point on portability, it's common to have "fake" or fakeish data for local development. For local dev, secrets might all be fake and not need to connect to a real secret manager. Moving to an abstraction avoids error-prone spaghetti code like:

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

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

Vulnerabilities

No vulnerabilities reported

Install aws-secret-sidecar-injector

You can download it from GitHub.

Support

For any new features, suggestions and bugs create an issue on GitHub. If you have any questions check and ask questions on community page Stack Overflow .

Find more information at: