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

Secrets used as input resources are double base64 encoded when used in stringData #445

Open
carpenterm opened this issue Jul 31, 2023 · 1 comment
Labels
bug This issue describes a defect or unexpected behavior carvel-accepted This issue should be considered for future work and that the triage process has been completed

Comments

@carpenterm
Copy link

What steps did you take:

  1. Author a new SecretTemplate that uses stringData to build a multiline secret
  2. Specify inputResources that are of kind Secret
  3. Reference the inputResources in the stringData field
  4. Apply the SecretTemplate

Example:

apiVersion: secretgen.carvel.dev/v1alpha1
kind: SecretTemplate
metadata:
  name: my-templated-secret
spec:
  inputResources:
  - name: my-input-secret
    ref:
      apiVersion: v1
      kind: Secret
      name: a-password-secret
  template:
    stringData:
      config: |
        #This is an example
        someKey = $(.my-input-secret.data.password)

What happened:
The values from the password secret were retrieved (base64 encoded) and added to the secret, the resulting string in the stringData field was then base64 encoded again. Meaning when my application decodes the templated secret, it doesn't contain the password, but rather the base64 contents of the original secrets. This makes the templated secret unusable.

What did you expect:
I expected the values to be base64 decoded so that my application could use them.

Anything else you would like to add:

Environment:

  • secretgen-controller version: v0.14.8
  • Kubernetes version: v1.24.15

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

@carpenterm carpenterm added bug This issue describes a defect or unexpected behavior carvel-triage This issue has not yet been reviewed for validity labels Jul 31, 2023
@renuy renuy moved this to To Triage in Carvel Aug 22, 2023
@renuy renuy added carvel-accepted This issue should be considered for future work and that the triage process has been completed and removed carvel-triage This issue has not yet been reviewed for validity labels Aug 22, 2023
@renuy renuy moved this from To Triage to Prioritized Backlog in Carvel Sep 1, 2023
@devthejo
Copy link
Contributor

there was a workaround using ExternalSecrets here #389 and I found a workaround using kyverno Policy (tricky but working), here is my helm template:

apiVersion: kyverno.io/v1
kind: Policy
metadata:
  name: template-secret-amqp
  annotations:
    argocd.argoproj.io/sync-wave: "-1"
spec:
  background: true
  rules:
    - name: gensecret
      match:
        any:
        - resources:
            kinds:
              - Secret
            names:
              - rabbitmq
      context:
      - name: password
        apiCall:
          urlPath: "/api/v1/namespaces/{{`{{`}}request.namespace{{`}}`}}/secrets/rabbitmq"
          jmesPath: 'data."rabbitmq-password"'
      generate:
        apiVersion: v1
        kind: Secret
        name: amqp
        namespace: {{ .Release.Namespace }}
        data:
          data:
            uri: "{{`{{`}}base64_encode('amqp://user:{{`{{`}}base64_decode(password){{`}}`}}@rabbitmq.rabbitmq-production.svc'){{`}}`}}"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue describes a defect or unexpected behavior carvel-accepted This issue should be considered for future work and that the triage process has been completed
Projects
Status: Prioritized Backlog
Development

Successfully merging a pull request may close this issue.

3 participants