Skip to content
New issue

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

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

Already on GitHub? # to your account

Add a value to the generated secret that allows a client to check that the sealed secret was actually decrypted successfully #1343

Open
dwt opened this issue Oct 10, 2023 · 2 comments
Labels
backlog Issues/PRs that will be included in the project roadmap

Comments

@dwt
Copy link

dwt commented Oct 10, 2023

Which component:
controller: registry.gitlab.com/bkkvbu/platform/sealed-secrets/controller:v0.15.0

Is your feature request related to a problem? Please describe.
There are basically two use cases that trigger this request:

  • We've had several cases where an update to a sealed secret was / could not be not decrypted correctly. This was hard to debug, because it was basically only detectable by looking at the log output of the sealed secret controller.
  • We've had several instances where an old version of the secret was used because the new version wasn't yet decrypted.

Describe the solution you'd like
I would like to have the generation and / or resourceVersion of the sealed secret be part of the ownerReferences. That way it is easy to check wether the decryption worked as expected and it is also actually possible to wait for the sealed secretto be decrypted to a secret.

Describe alternatives you've considered
We're currently using code like this to work around this problem:

#!/usr/bin/env bash

ns="--namespace cattle-monitoring-system"

next_generation=$(
  kubectl get $ns -oyaml \
    sealedsecret rancher-monitoring-grafana-admin \
  | yq '.metadata.generation + 1 // 0'
)
yq ".spec.template.metadata.annotations.SealedSecretGeneration=\"$next_generation\"" \
  sealedsecret.yml | sponge sealedsecret.yml

# Install sealed secret
kubectl $ns apply -f sealedsecret.yml

# wait for secret to be updated
function generation_from_secret() {
  kubectl get $ns -oyaml secret rancher-monitoring-grafana-admin | yq .metadata.annotations.SealedSecretGeneration
}


while [[ "$(generation_from_secret)" != "$next_generation" ]] ; do
  sleep 1
done
# install rancher-monitoring helm chart
helm diff upgrade $ns rancher-monitoring rancher/rancher-monitoring --version 102.0.0+up40.1.2 -f values-dev.yaml --allow-unreleased
# helm install $ns rancher/rancher-monitoring --version 102.0.0+up40.1.2 -f values.yaml

While this works, it is clunky and hard to extend to all our projects. Also its not easily feasible to extend tools like helm to be able to wait for the secret to update without this being natively supported (AFAIK).

@dwt dwt added the triage Issues/PRs that need to be reviewed label Oct 10, 2023
@alvneiayu
Copy link
Collaborator

hi @dwt

We are investigating and trying to reproduce your problem. I will come back as soon as possible with feedback.

Thanks a lot

Álvaro

@agarcia-oss agarcia-oss added backlog Issues/PRs that will be included in the project roadmap and removed triage Issues/PRs that need to be reviewed labels Oct 26, 2023
@agarcia-oss
Copy link
Member

Hi @dwt We've noticed that your sealed secrets controller is quite outdated. We recently included an extended status view (versions above 0.22.0 should be able to report whenever a Sealed Secrets is not updated, provided you've updated as well the sealed secrets CRD in your installation.
An example report will be like this:

NAME        STATUS                                   SYNCED   AGE
my-secret   no key could decrypt secret (password)   False    25m

Will this be a solution to your problem?
Regards

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
backlog Issues/PRs that will be included in the project roadmap
Projects
None yet
Development

No branches or pull requests

3 participants