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.

Sign up for GitHub

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

Jump to bottom

Feature: support secret target #10

Closed
cortopy opened this issue Jan 17, 2022 · 6 comments
Closed

Feature: support secret target #10

cortopy opened this issue Jan 17, 2022 · 6 comments

Comments

@cortopy
Copy link

cortopy commented Jan 17, 2022

Currently only configMap is supported as target. It feels to me like that's the obvious choice for distributing a ca file. However, a lot of off-the-shelf applications out there only support mounting ca files via secrets

Would it be possible to add it for compatibility reasons?
@JoshVanL
Copy link
Collaborator

Hi @cortopy, there is no technical reason why adding Secret as a target could not be done, however is poses security implications (trust would be able read + write all Secrets in all namespaces). If added, we would likely want this feature disabled by default, and users would have to explicitly toggle that they 1. want this target available, and 2. grant and understand they are giving trust the permissions to do this.

@cortopy
Copy link
Author

cortopy commented Jan 17, 2022

thanks @JoshVanL for such a quick answer. I hadn't thought of that but the path you propose sounds excellent

@james-callahan
Copy link

As a mitigation to that risk, perhaps a suggestion for RBAC on secret to explicitly list resource names?

rudexi pushed a commit to Japannext/trust-manager that referenced this issue Jan 30, 2023
Supporting a secret target
6d6fe52 
This was requested in cert-manager#10

Motivation:
Many helm charts/operators support a certificate authority mount only in the form of a Secret, and do not support ConfigMap. This is due to the fact that certificate authority is often shipped with TLS-type secrets (along with their certificate and key).
cert-manager also require a certificate authority in the form of a Secret for its Vault issuer.

trust-manager should support the target being a Secret, along with a ConfigMap, to guarantee maximum usability.

For security concerns, we will allow trust-manager to only view/update a given list of managed secrets in the helm chart.

Signed-off-by: Guillaume Ludinard <guillaume.ludinard@japannext.co.jp>
@rudexi rudexi mentioned this issue Jan 30, 2023
Closed
rudexi pushed a commit to Japannext/trust-manager that referenced this issue Feb 1, 2023
Supporting a secret target
45ac699 
This was requested in cert-manager#10

Motivation:
Many helm charts/operators support a certificate authority mount only in the form of a Secret, and do not support ConfigMap. This is due to the fact that certificate authority is often shipped with TLS-type secrets (along with their certificate and key).
cert-manager also require a certificate authority in the form of a Secret for its Vault issuer.

trust-manager should support the target being a Secret, along with a ConfigMap, to guarantee maximum usability.

For security concerns, we will allow trust-manager to only view/update a given list of managed secrets in the helm chart.

Signed-off-by: Guillaume Ludinard <guillaume.ludinard@japannext.co.jp>
rudexi pushed a commit to Japannext/trust-manager that referenced this issue Feb 1, 2023
Supporting a secret target
c92a5ef 
This was requested in cert-manager#10

Motivation:
Many helm charts/operators support a certificate authority mount only in the form of a Secret, and do not support ConfigMap. This is due to the fact that certificate authority is often shipped with TLS-type secrets (along with their certificate and key).
cert-manager also require a certificate authority in the form of a Secret for its Vault issuer.

trust-manager should support the target being a Secret, along with a ConfigMap, to guarantee maximum usability.

For security concerns, we will allow trust-manager to only view/update a given list of managed secrets in the helm chart.

Signed-off-by: Guillaume Ludinard <guillaume.ludinard@japannext.co.jp>
rudexi pushed a commit to Japannext/trust-manager that referenced this issue Feb 8, 2023
Supporting a secret target
f5b7c69 
This was requested in cert-manager#10

Motivation:
Many helm charts/operators support a certificate authority mount only in the form of a Secret, and do not support ConfigMap. This is due to the fact that certificate authority is often shipped with TLS-type secrets (along with their certificate and key).
cert-manager also require a certificate authority in the form of a Secret for its Vault issuer.

trust-manager should support the target being a Secret, along with a ConfigMap, to guarantee maximum usability.

For security concerns, we will allow trust-manager to only view/update a given list of managed secrets in the helm chart.

Signed-off-by: Guillaume Ludinard <guillaume.ludinard@japannext.co.jp>
rudexi pushed a commit to Japannext/trust-manager that referenced this issue Feb 8, 2023
Supporting a secret target
f684c61 
This was requested in cert-manager#10

Motivation:
Many helm charts/operators support a certificate authority mount only in the form of a Secret, and do not support ConfigMap. This is due to the fact that certificate authority is often shipped with TLS-type secrets (along with their certificate and key).
cert-manager also require a certificate authority in the form of a Secret for its Vault issuer.

trust-manager should support the target being a Secret, along with a ConfigMap, to guarantee maximum usability.

For security concerns, we will allow trust-manager to only view/update a given list of managed secrets in the helm chart.

Signed-off-by: Guillaume Ludinard <guillaume.ludinard@japannext.co.jp>
rudexi pushed a commit to Japannext/trust-manager that referenced this issue Feb 14, 2023
Supporting a secret target
d023f79 
This was requested in cert-manager#10

Motivation:
Many helm charts/operators support a certificate authority mount only in the form of a Secret, and do not support ConfigMap. This is due to the fact that certificate authority is often shipped with TLS-type secrets (along with their certificate and key).
cert-manager also require a certificate authority in the form of a Secret for its Vault issuer.

trust-manager should support the target being a Secret, along with a ConfigMap, to guarantee maximum usability.

For security concerns, we will allow trust-manager to only view/update a given list of managed secrets in the helm chart.

Signed-off-by: Guillaume Ludinard <guillaume.ludinard@japannext.co.jp>
@n9 n9 mentioned this issue Aug 17, 2023
Open
@erikgb
Copy link
Contributor

erikgb commented Aug 28, 2023

I support adding secrets as an opt-in target for bundles. There are just so many tools that only support obtaining CA certificates from secrets. And one could argue that even if a CA certificate bundle is not strictly secret, defining who you trust is definitely important for overall security.

As a mitigation to that risk, perhaps a suggestion for RBAC on secret to explicitly list resource names?

@james-callahan I don't think this is possible in general. As a user of trust-manager, I would expect to be allowed to express the secret name in the bundle resource. AFAIK the controller-runtime mechanics (and Kubernetes API) do not really support watching resources cluster-wide by name(s).

@Jiawei0227 Jiawei0227 mentioned this issue Oct 7, 2023
Merged
@erikgb
Copy link
Contributor

erikgb commented Oct 18, 2023

I believe is issue was fixed by #193

/close

@jetstack-bot
Copy link
Contributor

@erikgb: Closing this issue.

In response to this:

I believe is issue was fixed by #193

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@erikgb @cortopy @JoshVanL @jetstack-bot @james-callahan