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

sealed-secrets API ValidateSealedSecret missing certURL Option #1208

Closed
rowi1de opened this issue May 13, 2023 · 7 comments
Closed

sealed-secrets API ValidateSealedSecret missing certURL Option #1208

rowi1de opened this issue May 13, 2023 · 7 comments
Labels

Comments

@rowi1de
Copy link

rowi1de commented May 13, 2023

Which component:
kubeseal

Describe the bug
Using the validate function will result in an error when the service to fetch the certificate is not reachable

To Reproduce
Use AWS EKS with calico

Expected behavior

  • The ValidateSealedSecret API should work, when the service is not reachable inside the cluster.
  • Other APIs allow fetching the certificate from provided certURL

Additional context

func ValidateSealedSecret(ctx context.Context, clientConfig ClientConfig, controllerNs, controllerName string, in io.Reader) error {

Similar to #1206

@rowi1de rowi1de added the triage Issues/PRs that need to be reviewed label May 13, 2023
@alvneiayu
Copy link
Collaborator

hi @rowi1de

For security reason, the only way to validate the secret is to consume the endpoint exposed by the controller. If we want to do it offline, we need the private key to validate the secret. It is not a good idea to provide a feature like this, because it is not a good practice to export or to consume the private keys outside the controller.

We are accepting to use the private keys outside the cluster only in disaster situations. For example, you need to do a backup of your keys decrypting the secrets. But to validate the sealed secrets, we don't think that it is a good idea thinking in security reasons.

Thanks

Álvaro

@alvneiayu alvneiayu removed the triage Issues/PRs that need to be reviewed label May 30, 2023
@rowi1de
Copy link
Author

rowi1de commented Jun 1, 2023

hi @rowi1de

For security reason, the only way to validate the secret is to consume the endpoint exposed by the controller. If we want to do it offline, we need the private key to validate the secret. It is not a good idea to provide a feature like this, because it is not a good practice to export or to consume the private keys outside the controller.

We are accepting to use the private keys outside the cluster only in disaster situations. For example, you need to do a backup of your keys decrypting the secrets. But to validate the sealed secrets, we don't think that it is a good idea thinking in security reasons.

Thanks

Álvaro

Hey @alvneiayu,

Thanks for the answer 👌🏻 the explanation makes totally sense from a security point of view.

However now I wonder why the validation fails if the certificate can’t be fetched internally? I was under the assumption fetching the certificate is always about the Public Key for encryption reasons and the private key is purely internal and only accessible by that controller itself?
EDIT: I need to double check which part of the validate fails, if it is the call to verify api. Could be related to #1206

Kind Regards
Robert

@alvneiayu
Copy link
Collaborator

hi @rowi1de

What is the error that you are reproducing trying to validate the sealed secrets? Could you show me logs, please?

I mean, the validation process is consuming and endpoint to validate your Sealed Secrets and your public certificate is consumed also by the kubeseal though an endpoint exposed by the controller. Then validation and fetch certificate processes need the endpoints accessible in the controller to complete successfully the process.

If you are reproducing problem fetching the certificate, it seems that you are having connectivity problem with the controller and you will suffer also errors validating the sealed secrets.

Thanks

Álvaro

@alemorcuq
Copy link
Collaborator

alemorcuq commented Jun 1, 2023

I was under the assumption fetching the certificate is always about the Public Key for encryption reasons and the private key is purely internal and only accessible by that controller itself?

Yes, the certificate you fetch is the public key, which is used to encrypt the secrets. However, to validate an encrypted secret what you need is the private key. The validation process works by trying to decrypt the secret using the private key. What kubeseal does to validate a Sealed Secret is make a request to an endpoint in the controller that verifies the Sealed Secret by attempting to decrypt it. This way the private key never leaves the cluster.

You can't validate a Sealed Secret without the private key.

@rowi1de
Copy link
Author

rowi1de commented Jun 1, 2023

hi @rowi1de

What is the error that you are reproducing trying to validate the sealed secrets? Could you show me logs, please?

kubeseal --validate --cert $SEALED_SECRETS_CERT --controller-namespace infrastructure --controller-name sealed-secrets
or kubeseal --fetch-cert --controller-namespace infrastructure --controller-name sealed-secrets both fail with:

2023/06/01 11:22:56 Connection to sealed secrets with (Namespace: infrastructure / ServiceName: sealed-secrets)
2023/06/01 11:22:56 Setup sealer: cannot fetch certificate: error trying to reach service: Address is not allowed

The problem is not a core problem of sealed-secrets probably, but the issue can happen on AWS EKS with different network interface providers .e.g. calico
It currently requires a lot of custom code (Proxy via Ambassador Pattern), similar to described here: https://medium.com/@denisstortisilva/kubernetes-eks-calico-and-custom-admission-webhooks-a2956b49bd0d

@github-actions
Copy link
Contributor

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.

@github-actions github-actions bot added the Stale label Jun 17, 2023
@github-actions
Copy link
Contributor

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.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jun 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants