Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow the webhook url to be set as an external secret #1918

Open
pedroamantecon opened this issue Mar 18, 2024 · 5 comments
Open

Allow the webhook url to be set as an external secret #1918

pedroamantecon opened this issue Mar 18, 2024 · 5 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/backlog Higher priority than priority/awaiting-more-evidence. target/kubernetes Issues relating to kubernetes cluster scanning

Comments

@pedroamantecon
Copy link

As the GitOps approach becomes more prevalent, having a hardcoded webhook url in a repository is not ideal and certainly not secure. I think having the ability to store any sensitive information as an external secret or encrypted in any way would be a logical step.

@pedroamantecon pedroamantecon added the kind/feature Categorizes issue or PR as related to a new feature. label Mar 18, 2024
@chen-keinan
Copy link
Contributor

@pedroamanteconyou mean to have is as a k8s secret ? or totally external to system

@pedroamantecon
Copy link
Author

Yeah as a k8s secret

@chen-keinan
Copy link
Contributor

@pedroamantecon you want the secret to be deployed by the user separately from trivy-operator deployment, or it will be deployed as part of trivy-operator deployment ?

@chen-keinan chen-keinan added target/kubernetes Issues relating to kubernetes cluster scanning priority/backlog Higher priority than priority/awaiting-more-evidence. labels Mar 19, 2024
@pedroamantecon
Copy link
Author

Separately. In my case specifically, I deploy secrets using KSOPS

@Starttoaster
Copy link
Contributor

Starttoaster commented Apr 16, 2024

Fwiw, I publish all my kubernetes manifests to git repos as well. When I need to plant secrets in a yaml file, in CI I'll use a tool like j2cli to do environment variable substitution in the yaml file to plant the secret there from my CI job's environment variables. Which is a much simpler solution than requiring every kubernetes tool I use to have an option to respect an externally managed Secret.

Not necessarily saying it shouldn't also be made to respect externally managed Secrets. But there are other options for GitOps patterns for kubernetes manifests that don't involve putting the actual secret in the repo.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. priority/backlog Higher priority than priority/awaiting-more-evidence. target/kubernetes Issues relating to kubernetes cluster scanning
Projects
None yet
Development

No branches or pull requests

3 participants