Able to access pulbic key when using own key pair
BlueCog opened this issue · comments
Hi All,
We're using own key pairs on our sealed-secrets implementations. We are hosting the pulbic keys seperately. But is seems from the docs that there is also an internal API of the sealed-secrets controller that could be used to retrieve the pulbic keys. Is this correct?
I've tried accessing te service provided with sealed-secrets (Service: sealed-secrets-controller on 8080) but i'm not getting an answer...
Greets!
Hi @BlueCog the public key certificate can be obtained using the kubeseal command as explained here
$kubeseal --fetch-cert
-----BEGIN CERTIFICATE-----
...
That will retrieve the public key from the controller internal endpoint :/v1/cert.pem
Hi @BlueCog the public key certificate can be obtained using the
kubesealcommand as explained here$kubeseal --fetch-cert -----BEGIN CERTIFICATE----- ...That will retrieve the public key from the controller internal endpoint :
/v1/cert.pem
Hi @agarcia-oss thanks for the reply!
As I gather from you answer and the docs, SealedSecrets primarily supports (with --fetch-cert) the use of a single pair of keys (private and public) managed by the SealedSecrets Controller, and that the --fetch-cert command is intended to fetch the public key from this controller.
In our case, we are dealing with multiple private and public keys*. While self-hosting these (public) keys and setting up our internal automation to manage and publish them isn't a major issue, it does introduce additional components and complexity into our setup. This complexity is something we are hoping to minimize as users of SealedSecrets.
We were exploring if there might be a more streamlined way to handle multiple public keys directly through SealedSecrets, especially through extensions to the --fetch-cert command to allow specifying custom public keys. Our aim is to maintain simplicity and reduce the need for additional tooling or custom scripts.
Example (non working scenario):
kubeseal --fetch-cert --cert-url https://sealed-secrets-controller/v1/custom_cert1.pem
Any insights or suggestions you might have on how we can better manage this scenario within the framework of SealedSecrets would be greatly appreciated.
Thank you for your time and assistance.
*This need arises due to shared responsibilities between the provider and tenant of our cluster, as well as the necessity for portability across multiple clusters. The use of multiple keys allows us to maintain distinct control and access boundaries, which is crucial for our operational model.
This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.
Due to the lack of activity in the last 7 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.