carvel-dev / secretgen-controller Goto Github PK

Describe the solution you'd like

• base image on scratch since secretgen does not communicate with external services and generally does not need OS
• remove unnecessary PATH env var

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 would like to work on this issue.

What steps did you take:

1. Create a SecretTemplate with non-secret InputResources that do not exist yet
2. Wait 5 minutes
3. Create the InputResources

What happened:
You must wait numerous minutes for reconcilation to occur and for SecretTemplate to show Ready=true.

What did you expect:
SecretTemplate to re-reconcile faster.

Anything else you would like to add:

As discussed in #68 this is not a problem for when a Service Account is not specified and InputResources are secrets, we rely on watch mechanisms to notice changes. However we do not use Watch for non-secret inputs (See above issue for details why)

When SecretTemplate specifies a ServiceAccount and successfully reconciles we currently periodically requeue to detect changes to those InputResources. However, when reconciliation returns an error, we are currently relying on controller-runtime's exponential backoff mechanism. This means it will maximally only requeue every 16minutes.

For error conditions that may eventually resolve without making changes to SecretTemplate, we should requeue rather than rely on the backoff. The conditions where this is appropriate are:

• When an input resource cannot be fetched
• When templating fails because a resolved input resource does not contain the necessary fields

(Note: This was raised in the original PR here #66 (comment))

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.

Describe the problem/challenge you have
Shreyas Sreenivas 21 hours ago
Hi,
Needed some inputs regarding the Secret-Gen-Controller SecretImport implementation and possible changes.
Secret Import duplicates the secret into a new namespace. This duplicated secret duplicates all the Annotations and Labels from the source secret (DeepCopy of the secret). This is causing an issue in the TMC managedSecret controller, this duplicate secret is getting cleaned up as the controller use annotations to map it against the server intent and the duplicate secret has the same unique identifier (TMC related ID ) in the secret annotations.

Your thoughts and suggestion on solving this problem ? (edited)

Describe the solution you'd like
Request for change:
Can secret gen controller on duplication of the secret add an extra annotation which depicts that the secret is created via secret-import. In the present implementation, we see that the duplicate secret does have a owner ref to secret import CR, but annotation should be simpler. By this change we can avoid the secret getting deleted from the controller

OR, can the secret gen controller avoid copying the annotations of the secrets ?

Anything else you would like to add:
In slack thread it looked like there were two votes for the second proposal ("avoid copying certain annotations")

See kapp-controller's issue for additional context: carvel-dev/kapp-controller#319

Describe the problem/challenge you have

I want to use the SecretTemplate API with implementations of the Service Binding Specification for Kubernetes.

Describe the solution you'd like

Make the SecretTemplate API a Provisioned Service as defined in the Service Binding Specification for Kubernetes.

Anything else you would like to add:

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 would like to work on this issue.

Describe the problem/challenge you have

I need to bootstrap Linkerd with an ECDSA P-256 certificate.

Describe the solution you'd like

I would like to use the secretgen controller to create a ECDSA P-256 certificate for use by graduated CNCF project Linkerd. Linkerd does not support the RSA certs created by the secretgen controller.

Anything else you would like to add:

Describe the problem/challenge you have
We can create secrets from different Namespaces with SecretTemplate

Describe the solution you'd like
Enable option in metadata to add namespace

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 would like to work on this issue.

What steps did you take:
Triggered a tag t1 on commit x and for some reason release action did not pass.
Triggered a new tag t2 on commit x and now release action passed and uploaded artefacts in draft release, but these artifacts have wrong info like tag. It is publishing file like release.yaml and package.yaml with tag t1 instead of t2.

What happened:
[A small description of the issue]

What did you expect:
It should always pick latest tag that is t2

Anything else you would like to add:
[Additional information that will assist in solving the issue.]

Environment:

• secretgen-controller version (execute kubectl get deployment -n secretgen-controller secretgen-controller -o yaml and the annotation is kbld.k14s.io/images):
• Kubernetes version (use kubectl version)

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.

What steps did you take:

apiVersion: vendir.k14s.io/v1alpha1
kind: Config
directories:
- path: distributions/carvel
  contents:
  - path: secretgen-controller
    githubRelease:
      slug: vmware-tanzu/carvel-secretgen-controller
      latest: true
      assetNames:
      - package.yml

What happened:

vendir: Error: Syncing directory 'distributions/carvel':
  Syncing directory 'secretgen-controller' with github release contents:
    Finding checksums in release notes:
      Expected to find sha256 checksum for file 'package.yml'

What did you expect:
to resolve the package.yml release artifact

Anything else you would like to add:

The digests for the latest release 0.12.0 look like:

59c60670b23aa2f2c53d6a17a643026c854f86d2ae2e402bc57c121d22ec15c8  ./tmp/release.yml
61432bcb914b779243e38da9b1b78ce94065c80735775b209b56d096b858fb65  carvel-artifacts/packages/secretgen-controller.carvel.dev/package.yml
8f185deaa02964663bc3cedcb7c0af46151676e7c2abc2b69ff04178f87f28fe  carvel-artifacts/packages/secretgen-controller.carvel.dev/package-metadata.yml

The digests for 0.11.0 look like:

5c95408656d898f724df7a29ec4052762a94711a8677637625fbb770af2f3cf4  release.yml
aa1326743e61eb8e9e1122668a9434961a47c36982b65e4d33cc08eab0618dd5  package.yml
55338cd490a6932c857e2035ed552b0a21e07bd2f0a46d4f5d0d2419b2323333  package-metadata.yml

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.

Describe the problem/challenge you have
Sometimes isn't possible to predict what namespaces need to access a shared secret.

Describe the solution you'd like
It would be nice to have the possibility to share the secret to any namespace via a flag.

Anything else you would like to add:
N/A

Thank you

Describe the problem/challenge you have

#66 Introduced the SecretTemplate API. This allows you to define arbitrary input resources that are used to generate a new Kubernetes Secret based on templating.

One of the fields that is available for templating within the Secret is type. Given this field is immutable the question is what should happen if this value changes within the template.

This could change if someone updates the SecretTemplate type field directly .eg. type: foo to type: bar or if they are using templating and the field changes. e.g. type: $(.resource.data.foo).

The current behaviour is that SecretTemplate attempts to update the Secret but fails. A user will have to delete and recreate the SecretTemplate to get the new value.

Describe the solution you'd like
This may not be a huge issue as it's fairly unlikely that type will be a dynamic field. However if someone typos the type field being able to simply update the template would be nice.

So for changes to type we should consider deleting and re-creating the entire secret.

Anything else you would like to add:
More context in this comment #66 (comment)

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 would like to work on this issue.

What steps did you take:
Just trying to install secretgetn-controller, using kubectl:

kubectl apply -f https://github.com/vmware-tanzu/carvel-secretgen-controller/releases/latest/download/release.yml

What happened:
the command finished with an error :

namespaces "secretgen-controller" not found

Eventually, the namespace is created but without any resources ( no deployment, pods and ..)

customresourcedefinition.apiextensions.k8s.io/secretexports.secretgen.carvel.dev created
customresourcedefinition.apiextensions.k8s.io/secretimports.secretgen.carvel.dev created
customresourcedefinition.apiextensions.k8s.io/certificates.secretgen.k14s.io created
customresourcedefinition.apiextensions.k8s.io/passwords.secretgen.k14s.io created
customresourcedefinition.apiextensions.k8s.io/rsakeys.secretgen.k14s.io created
customresourcedefinition.apiextensions.k8s.io/sshkeys.secretgen.k14s.io created
namespace/secretgen-controller created
serviceaccount/secretgen-controller-sa created
clusterrole.rbac.authorization.k8s.io/secretgen-controller-cluster-role created
clusterrolebinding.rbac.authorization.k8s.io/secretgen-controller-cluster-role-binding created
Error from server (NotFound): error when creating "https://github.com/vmware-tanzu/carvel-secretgen-controller/releases/latest/download/release.yml": namespaces "secretgen-controller" not found

What did you expect:
create the namespace if it does not exist, before trying to install the resources there.

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.

As described in carvel-dev/kapp-controller#368 and carvel-dev/kapp#315, it might be helpful for us to consider adding a security scan as part of a nightly build process. This would help us monitor and triage security alerts better for secretgen-controller. In particular, conducting a scan of the secretgen-controller image could be helpful.

Note: if setting up trivy is trivial, consider setting up for other carvel repos.

Question

Is it possible to better document how we can, post Secret, SecretExport and Secret Placeholder created consume the secret using the property imagePullSecrets within a Pod or Deployment ?

Example of resources to be created

cat <<EOF | kubectl apply -f -
---
apiVersion: v1
kind: Secret
metadata:
  name: reg-creds-docker
  namespace: demo
type: kubernetes.io/dockerconfigjson
stringData:
  .dockerconfigjson: |
    {
      "auths": {
        "index.docker.io": {
          "username": "xxxxxx",
          "password": "user",
          "auth": ""
        }
      }
    } 
---
apiVersion: secretgen.carvel.dev/v1alpha1
kind: SecretExport
metadata:
  name: reg-creds-docker
  namespace: demo
spec:
  toNamespaces:
  - "*"
---
apiVersion: v1
kind: Secret
metadata:
  name: my-reg-creds
  namespace: demo
  annotations:
    secretgen.carvel.dev/image-pull-secret: ""
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: e30K

Next, we must update the service account to patch it to set "imagePullSecrets": [{"name":"my-reg-creds"} but apparently this is not enough as no secret is copied within the namespace demo1

kc create ns demo1
kubectl patch serviceaccount default -n demo1 -p '{"imagePullSecrets": [{"name":"my-reg-creds"}]}'
kc get sa,secret -n demo1
NAME                     SECRETS   AGE
serviceaccount/default   1         100s

NAME                         TYPE                                  DATA   AGE
secret/default-token-h8cvt   kubernetes.io/service-account-token   3      100s

Question: Could the patch step be done automatically ? How ?

What steps did you take:

I created a Password with some labels. Then I wanted to add another label and was hoping that this change gets pushed down to the Secret. Because this did not happen, I deleted the Secret in the hopes that the secretgen-controller would reconcile and recreate the Secret, now with the updated set of labels from the Password:

Steps taken:

• install the secret-gen controller:

  k apply -f https://github.com/vmware-tanzu/carvel-secretgen-controller/releases/download/v0.9.1/release.yml

• create a password

  cat <<'EOF' | k apply -f -
  kind: Password
  apiVersion: secretgen.k14s.io/v1alpha1
  metadata:
    name: the-passoword
    labels:
      initalLabel: something
  spec:
    length: 10
    secretTemplate:
      type: Secret
      stringData:
        password: $(value)
  EOF

• inspect the labels on the Password and the Secret:

  k get password,secret -o yaml | yq -r '.items[] | "\(.kind): \(.metadata.name) => \(.metadata.labels)"'
  
  Password: the-passoword => {"initalLabel":"something"}
  Secret: the-passoword => {"initalLabel":"something"}

• change labels on the Password:

  k label password/the-passoword anotherLabel=somethingElse
  
  password.secretgen.k14s.io/the-passoword labeled

• inspect the labels again:

   k get password,secret -o yaml | yq -r '.items[] | "\(.kind): \(.metadata.name) => \(.metadata.labels)"'
  
  Password: the-passoword => {"anotherLabel":"somethingElse","initalLabel":"something"}
  Secret: the-passoword => {"initalLabel":"something"}

• delete the secret:

  k delete secret the-passoword

• see, that the secret is gone:

  k get password,secret -o yaml | yq -r '.items[] | "\(.kind): \(.metadata.name) => \(.metadata.labels)"'
  
  Password: the-passoword => {"anotherLabel":"somethingElse","initalLabel":"something"}
  # Note, we don't see no `Secret` anymore.

• see, that there are no reconcile errors or something:

  k get password/the-passoword -o yaml | yq -y .status
  
  conditions:
  - status: 'True'
    type: ReconcileSucceeded
  friendlyDescription: Reconcile succeeded
  observedGeneration: 1

What happened:

"Nothing". First the Password did not update the labels on the Secret it created. And then, after the Secret was deleted, the controller made not attempts to recreate the Secret again.

What did you expect:

I expected

• the controller to update the Secret's metadata when I update the Password's metadata
• the controller to recreate the Secret or give me an error and tell me it cannot recreate the secret (Because it does not know the original password, which cloud be a valid failure case IMHO)

Anything else you would like to add:

I could see that there are reasons to not reconcile the Secret, because the controller has no knowledge of the original password, and for some cases it might be better to not reconcile than to reconcile with a changed password. However, if that's the case I think we should at least call that out in the docs or, ideally, have the controller tell users about that in its status subresource.
I think it is "surprising" that the controller seems to be doing nothing at all once the secret is created.

This bug report outlines two different issues. Technically, I guess, they need to address different things (watching updates/deletion of secrets vs. watching updated of passwords). I am happy to split the issue. However, from a user's point of view, I think they are "the same" in the sense that the controller does not seem to reconcile at all.

There was a short discussion about this in #carvel.

Environment:

• secretgen-controller version

  k get deployment -n secretgen-controller secretgen-controller -o yaml | yq -r '.metadata.annotations["kbld.k14s.io/images"]'
  
  - origins:
    - local:
        path: /Users/dk/workspace/carvel-secretgen-controller
    - git:
        dirty: false
        remoteURL: [email protected]:vmware-tanzu/carvel-secretgen-controller
        sha: 3b76cf0602b6c377fca8589c5fa30b9f04fc51a0
        tags:
        - v0.9.1
    url: ghcr.io/vmware-tanzu/carvel-secretgen-controller@sha256:1f842b9c3e0ee164b450c10486d7b08eee0eacb754af42549aa64906221f7966
  

• Kubernetes version (use kubectl version)

  k version
  WARNING: version difference between client (1.21) and server (1.24) exceeds the supported minor version skew of +/-1
  Client Version: version.Info{Major:"1", Minor:"21", GitVersion:"v1.21.1", GitCommit:"5e58841cce77d4bc13713ad2b91fa0d961e69192", GitTreeState:"clean", BuildDate:"2021-05-12T14:18:45Z", GoVersion:"go1.16.4", Compiler:"gc", Platform:"linux/amd64"}
  Server Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.0", GitCommit:"4ce5a8954017644c5420bae81d72b09b735c21f0", GitTreeState:"clean", BuildDate:"2022-05-19T15:39:43Z", GoVersion:"go1.18.1", Compiler:"gc", Platform:"linux/amd64"}

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.

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.

Do some code review to ensure it is maintainable by this team. Some deliverables are,

• capture some knowledge in godocs
• make a boxes and lines diagram for the code
• update to go 1.16. (currently 1.13)
• e2e tests cover examples folder

Hey! As part of #66 the SecretTemplate API was introduced but we held off then on adding documentation. This was partially due to the possible confusion of the already existing SecretTemplate (part of password) that is already under docs/. As folks are started to use the API, it would be great to get some thorough docs and use cases in there and find a way for them to coexist with the previous secret template.

Hello,

I'm an engineer from the RabbitMQ team. Our commercial operator is using the carvel toolchain and the tanzu-cluster-essential components (kapp and secret-gen controller) as prerequisite.

We are trying to produce a commercial arm64 image to solve a limitation on tanzu-net not supporting multi-arch image.

I can see that the tanzu-cluster-essential at the moment don't support multi-arch images commercially (probably for the same limitation on tanzunet registry).

What about the open source versions? I can see that I can install kapp on arm64
kapp deploy -a kc -f https://github.com/vmware-tanzu/carvel-kapp-controller/releases/latest/download/release.yml

but not secretgen controller:
kapp deploy -a sg -f https://github.com/carvel-dev/secretgen-controller/releases/latest/download/release.yml

where it seems is using the amd64 image.

Is there a way we can install secret-gen controller on arm64?

Thank you!

What steps did you take:
I'm trying to create a secret that references other generated secrets. The first secrets are created quickly, but the controller pod crashes when trying to resolve the fourth.

What happened:
The controller pod crashed

What did you expect:
The fourth secret to resolve, using data generated from the previous three

Anything else you would like to add:
Here are the inputs that I was using:

---
apiVersion: secretgen.k14s.io/v1alpha1
kind: SSHKey
metadata:
  name: worker-key
  namespace: concourse
spec: {}
---
apiVersion: secretgen.k14s.io/v1alpha1
kind: SSHKey
metadata:
  name: tsa-host-key
  namespace: concourse
spec: {}
---
apiVersion: secretgen.k14s.io/v1alpha1
kind: RSAKey
metadata:
  name: session-signing-key
  namespace: concourse
spec: {}
---
# Source: concourse/templates/web-secrets.yaml
apiVersion: secretgen.carvel.dev/v1alpha1
kind: SecretTemplate
metadata:
  name: concourse-web
  namespace: concourse
spec:
  inputResources:
  - name: session-signing-key
    ref:
      apiVersion: v1
      kind: Secret
      name: session-signing-key
  - name: tsa-host-key
    ref:
      apiVersion: v1
      kind: Secret
      name: tsa-host-key
  - name: worker-key
    ref:
      apiVersion: v1
      kind: Secret
      name: worker-key
template:
  data:
    host-key: $(.tsa-host-key.data.privateKey)
    session-signing-key: $(.session-signing-key.data.privateKey)
    worker-key-pub: $(.worker-key.data.authorizedKey)
    local-users: "dGVzdDp0ZXN0"

The list of secrets:

$ kubectl get secret -n concourse
NAME                  TYPE                     DATA   AGE
session-signing-key   Opaque                   2      15m
worker-key            kubernetes.io/ssh-auth   2      15m
tsa-host-key          kubernetes.io/ssh-auth   2      15m
$ kubectl get secrettemplate -n concourse
NAME            DESCRIPTION   AGE
concourse-web   Reconciling   15m

And here are the controller pod logs:

pwall@Personal-MBP:~/src/petewall/cluster/deployments/concourse $ kubectl logs -n secretgen-controller secretgen-controller-667f6f9d67-zlt5m
{"level":"info","ts":1657380006.8805838,"logger":"sg.entrypoint","msg":"secretgen-controller","version":"0.10.3"}
{"level":"info","ts":1657380006.8806255,"logger":"sg.entrypoint","msg":"setting up manager"}
{"level":"info","ts":1657380007.2324445,"logger":"controller-runtime.metrics","msg":"Metrics server is starting to listen","addr":":8080"}
{"level":"info","ts":1657380007.2326853,"logger":"sg.entrypoint","msg":"setting up controllers"}
{"level":"info","ts":1657380007.2337837,"logger":"sg.entrypoint","msg":"starting manager"}
{"level":"info","ts":1657380007.2339766,"msg":"Starting metrics server","path":"/metrics"}
{"level":"info","ts":1657380007.2340772,"logger":"controller.sg-cert","msg":"Starting EventSource","source":"kind source: *v1alpha1.Certificate"}
{"level":"info","ts":1657380007.234097,"logger":"controller.sg-cert","msg":"Starting Controller"}
{"level":"info","ts":1657380007.2342255,"logger":"controller.sg-password","msg":"Starting EventSource","source":"kind source: *v1alpha1.Password"}
{"level":"info","ts":1657380007.2342393,"logger":"controller.sg-password","msg":"Starting Controller"}
{"level":"info","ts":1657380007.2342494,"logger":"controller.sg-secret","msg":"Starting EventSource","source":"kind source: *v1.Secret"}
{"level":"info","ts":1657380007.2342887,"logger":"controller.sg-secret","msg":"Starting EventSource","source":"kind source: *v1alpha1.SecretExport"}
{"level":"info","ts":1657380007.2342992,"logger":"controller.sg-secret","msg":"Starting EventSource","source":"kind source: *v1.Namespace"}
{"level":"info","ts":1657380007.2343037,"logger":"controller.sg-secret","msg":"Starting Controller"}
{"level":"info","ts":1657380007.2344172,"logger":"controller.sg-rsakey","msg":"Starting EventSource","source":"kind source: *v1alpha1.RSAKey"}
{"level":"info","ts":1657380007.2344322,"logger":"controller.sg-rsakey","msg":"Starting Controller"}
{"level":"info","ts":1657380007.2345197,"logger":"controller.sg-sshkey","msg":"Starting EventSource","source":"kind source: *v1alpha1.SSHKey"}
{"level":"info","ts":1657380007.2345417,"logger":"controller.sg-sshkey","msg":"Starting Controller"}
{"level":"info","ts":1657380007.234648,"logger":"controller.sg-template","msg":"Starting EventSource","source":"kind source: *v1.Secret"}
{"level":"info","ts":1657380007.2346628,"logger":"controller.sg-template","msg":"Starting EventSource","source":"kind source: *v1.Secret"}
{"level":"info","ts":1657380007.23467,"logger":"controller.sg-template","msg":"Starting EventSource","source":"kind source: *v1alpha1.SecretTemplate"}
{"level":"info","ts":1657380007.2346745,"logger":"controller.sg-template","msg":"Starting Controller"}
{"level":"info","ts":1657380007.2347345,"logger":"controller.sg-secexp","msg":"Starting EventSource","source":"kind source: *v1alpha1.SecretExport"}
{"level":"info","ts":1657380007.234757,"logger":"controller.sg-secexp","msg":"Starting EventSource","source":"kind source: *v1.Secret"}
{"level":"info","ts":1657380007.2347615,"logger":"controller.sg-secexp","msg":"Starting Controller"}
{"level":"info","ts":1657380007.2348795,"logger":"controller.sg-secimp","msg":"Starting EventSource","source":"kind source: *v1alpha1.SecretImport"}
{"level":"info","ts":1657380007.2348936,"logger":"controller.sg-secimp","msg":"Starting EventSource","source":"kind source: *v1.Secret"}
{"level":"info","ts":1657380007.234897,"logger":"controller.sg-secimp","msg":"Starting EventSource","source":"kind source: *v1alpha1.SecretExport"}
{"level":"info","ts":1657380007.2349007,"logger":"controller.sg-secimp","msg":"Starting EventSource","source":"kind source: *v1.Namespace"}
{"level":"info","ts":1657380007.2349072,"logger":"controller.sg-secimp","msg":"Starting Controller"}
{"level":"info","ts":1657380007.3345132,"logger":"controller.sg-password","msg":"Starting workers","worker count":1}
{"level":"info","ts":1657380007.3346202,"logger":"controller.sg-cert","msg":"Starting workers","worker count":1}
{"level":"info","ts":1657380007.334624,"logger":"controller.sg-rsakey","msg":"Starting workers","worker count":1}
{"level":"info","ts":1657380007.3347082,"logger":"controller.sg-sshkey","msg":"Starting workers","worker count":1}
{"level":"info","ts":1657380007.3352313,"logger":"controller.sg-secret","msg":"Starting workers","worker count":1}
{"level":"info","ts":1657380007.3354335,"logger":"sg.secret","msg":"Reconciling","request":"network/ddclient"}
{"level":"info","ts":1657380007.3355248,"logger":"controller.sg-template","msg":"Starting workers","worker count":1}
{"level":"info","ts":1657380007.3355968,"logger":"controller.sg-secexp","msg":"Starting workers","worker count":1}
{"level":"info","ts":1657380007.3356595,"logger":"sg.secret","msg":"Reconciling","request":"cert-manager/cert-manager-webhook-ca"}
{"level":"info","ts":1657380007.3357017,"logger":"controller.sg-secimp","msg":"Starting workers","worker count":1}
{"level":"info","ts":1657380007.3356607,"logger":"sg.template","msg":"reconciling","request":"concourse/concourse-web"}
{"level":"info","ts":1657380007.335777,"logger":"sg.secexp","msg":"Reconciling","request":"cert-manager/letsencrypt-prod"}
{"level":"info","ts":1657380007.3357766,"logger":"sg.secret","msg":"Reconciling","request":"cert-manager/letsencrypt-prod"}
{"level":"info","ts":1657380007.3359263,"logger":"sg.secexp","msg":"Reconciling","request":"ghost/ghost-tls"}
{"level":"info","ts":1657380007.3359742,"logger":"sg.secexp","msg":"Reconciling","request":"concourse/session-signing-key"}
{"level":"info","ts":1657380007.3359776,"logger":"sg.secret","msg":"Reconciling","request":"ghost/ghost-tls"}
{"level":"info","ts":1657380007.3360217,"logger":"sg.secexp","msg":"Reconciling","request":"concourse/tsa-host-key"}
{"level":"info","ts":1657380007.3360746,"logger":"sg.secexp","msg":"Reconciling","request":"cert-manager/letsencrypt-staging"}
{"level":"info","ts":1657380007.336126,"logger":"sg.secret","msg":"Reconciling","request":"concourse/session-signing-key"}
{"level":"info","ts":1657380007.3361483,"logger":"sg.secexp","msg":"Reconciling","request":"concourse/worker-key"}
{"level":"info","ts":1657380007.3362415,"logger":"sg.secret","msg":"Reconciling","request":"concourse/tsa-host-key"}
{"level":"info","ts":1657380007.3363152,"logger":"sg.secret","msg":"Reconciling","request":"cert-manager/letsencrypt-staging"}
{"level":"info","ts":1657380007.336336,"logger":"sg.secexp","msg":"Reconciling","request":"network/ddclient"}
{"level":"info","ts":1657380007.336398,"logger":"sg.secret","msg":"Reconciling","request":"concourse/worker-key"}
{"level":"info","ts":1657380007.3364034,"logger":"sg.secexp","msg":"Reconciling","request":"cert-manager/cert-manager-webhook-ca"}
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x133637d]

goroutine 392 [running]:
github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator.evaluateTemplate(_, _)
        github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator/secret_template_reconciler.go:280 +0x3d
github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator.(*SecretTemplateReconciler).reconcile(0xc0005bea00, {0x18f4ec8, 0xc00057a570}, 0xc000497380)
        github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator/secret_template_reconciler.go:131 +0x8d
github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator.(*SecretTemplateReconciler).Reconcile(0xc0005bea00, {0x18f4ec8, 0xc00057a570}, {{{0xc0005a1d50?, 0x15d69c0?}, {0xc0005a1d30?, 0xc000046800?}}})
        github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator/secret_template_reconciler.go:121 +0x36c
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Reconcile(0xc000433ae0, {0x18f4ec8, 0xc00057a4e0}, {{{0xc0005a1d50?, 0x15d69c0?}, {0xc0005a1d30?, 0xc0006bc5c0?}}})
        sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:114 +0x222
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler(0xc000433ae0, {0x18f4e20, 0xc000046040}, {0x155fa40?, 0xc000490180?})
        sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:311 +0x2e9
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem(0xc000433ae0, {0x18f4e20, 0xc000046040})
        sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:266 +0x1d9
sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2()
        sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:227 +0x85
created by sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2
        sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:223 +0x309

Environment:

• secretgen-controller version (execute kubectl get deployment -n secretgen-controller secretgen-controller -o yaml and the annotation is kbld.k14s.io/images):

    kbld.k14s.io/images: |
      - origins:
        - local:
            path: /home/runner/work/carvel-secretgen-controller/carvel-secretgen-controller
        - git:
            dirty: true
            remoteURL: https://github.com/vmware-tanzu/carvel-secretgen-controller
            sha: 7cf938231129673564646d851015d08630307efe
            tags:
            - v0.10.3
        url: ghcr.io/vmware-tanzu/carvel-secretgen-controller@sha256:00466d6beb98fdd8aed61642013ea0ba538bb496e84745c8c2e1871fdc54b1a9

• Kubernetes version (use kubectl version)

$ kubectl version
WARNING: This version information is deprecated and will be replaced with the output from kubectl version --short.  Use --output=yaml|json to get the full version.
Client Version: version.Info{Major:"1", Minor:"24", GitVersion:"v1.24.0", GitCommit:"4ce5a8954017644c5420bae81d72b09b735c21f0", GitTreeState:"clean", BuildDate:"2022-05-03T13:46:05Z", GoVersion:"go1.18.1", Compiler:"gc", Platform:"darwin/amd64"}
Kustomize Version: v4.5.4
Server Version: version.Info{Major:"1", Minor:"24+", GitVersion:"v1.24.0-2+59bbb3530b6769", GitCommit:"59bbb3530b6769e4935a05ac0e13c9910c79253e", GitTreeState:"clean", BuildDate:"2022-05-13T06:41:13Z", GoVersion:"go1.18.1", Compiler:"gc", Platform:"linux/amd64"}

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.

What steps did you take:
Deploy secretgen-controller on Openshift 4.11

What happened:
Deployment worked fine other than a warning.

Warning: would violate PodSecurity "restricted:v1.24": unrestricted capabilities (container "secretgen-controller" must set securityContext.capabilities.drop=["ALL"]), seccompProfile (pod or container "secretgen-controller" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

What did you expect:
Deployment to happen without the warning.

Environment:

• secretgen-controller version (execute kubectl get deployment -n secretgen-controller secretgen-controller -o yaml and the annotation is kbld.k14s.io/images): v0.12.0
• Kubernetes version (use kubectl version): 1.24

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.

Perhaps rely on https://github.com/mozilla/sops directly. The same as in https://github.com/k14s/kapp-controller/blob/3afee6986bac4a26b60d86c6131504d3404265be/pkg/template/sops.go

Btw: I really like the concept. It makes complete sense to implement this as a controller. In that way, the procedure to generate the secret is stored in git but you can't run into the situation where you accidentally commit your password. You will never touch the secret.

Releasing a new minor / major:

• OSS Release
  • Releasing via workflow.
  • Close any GitHub issues that have been delivered.
  • Add a link to the release on the issue.
• Update Documentation by generating a new docs version
• Communicate in Slack
• Add to "Announcements" in Next Community Meeting Agenda

Releasing a patch version and backporting a CVE:

• Validate which branch lines to backport the CVE to. Based on our private confluence page.
• For each line, e.g v0.9.x, v0.10.x, do the following:
  • Validate that the branch contains the latest patches, that no newer code was forgotten to be merged back in.
  • git checkout v0.9.x.
  • git checkout -b v0.9.<next-patch-version>.
  • Make the necessary fixes / cherry-picks.
  • git push origin v0.9.<next-patch-version>.
  • Make a PR.
  • Once approved, merge the changes back to the v0.9.x branch and git push the branch and delete your temporary branch used in the PR.
  • To Release: follow the instructions FROM THE BRANCH YOU ARE UPDATING at docs/dev.md#release in the repository. These will contain the relevant steps at each point of time in the project's history, e.g when updating v0.9.x the url will look like: https://github.com/vmware-tanzu/carvel-secretgen-controller/blob/v0.9.x/docs/dev.md#release

Describe the problem/challenge you have

As a secretgen-controller user
In order to use a generated secret in workloads that expect bcrypt encoded password
I need the SecretTemplate to support a bcrypt export format beyond base64 encoding

Describe the solution you'd like
[A clear and concise description of what you want to happen. If applicable a visual representation of the UX.]

SecretTemplate to support an additional format field with default base64 and an additional bcrypt value

See

In order to login to the WGE UI, you need to generate a bcrypt hash for your chosen password and store it as a secret in the Kubernetes cluster.

There are several different ways to generate a bcrypt hash, this guide uses gitops get bcrypt-hash from our CLI, which can be installed by following the instructions here.

Anything else you would like to add:

https://docs.gitops.weave.works/docs/installation/weave-gitops-enterprise/#6-configure-password

Similar request on ytt in carvel-dev/ytt#106

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 would like to work on this issue.

Describe the problem/challenge you have
I need to rename secret when importing it into a new namespace.

Describe the solution you'd like
Add field SecretRequest.spec.fromName which allows SecretRequest.name and SecretRequest.spec.fromName to be different.

Anything else you would like to add:
This is needed for scenario where static secrets exist in a common source namespace and have target namespaces embedded in their names. When these secrets are imported into their target namespaces the target names should be stripped.

What steps did you take:
Apply:

apiVersion: secretgen.k14s.io/v1alpha1
kind: Certificate
metadata:
  generateName: root-ca-cert-
  namespace: default
spec:
  isCA: true

What happened:
The secretgen-controller deployment dies:

secretgen-controller-78f5844ddb-fvn26 secretgen-controller E0706 13:07:02.746908       1 runtime.go:78] Observed a panic: "assignment to entry in nil map" (assignment to entry in nil map)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller goroutine 387 [running]:
secretgen-controller-78f5844ddb-fvn26 secretgen-controller k8s.io/apimachinery/pkg/util/runtime.logPanic({0x131cda0, 0x164d9d0})
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      k8s.io/[email protected]/pkg/util/runtime/runtime.go:74 +0x99
secretgen-controller-78f5844ddb-fvn26 secretgen-controller k8s.io/apimachinery/pkg/util/runtime.HandleCrash({0x0, 0x0, 0xc000289000})
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      k8s.io/[email protected]/pkg/util/runtime/runtime.go:48 +0x75
secretgen-controller-78f5844ddb-fvn26 secretgen-controller panic({0x131cda0, 0x164d9d0})
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      runtime/panic.go:1038 +0x215
secretgen-controller-78f5844ddb-fvn26 secretgen-controller github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator.GenerateInputs.Add({{0x13f7240, 0xc00049ca80}}, 0x0)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator/generate_inputs.go:23 +0x65
secretgen-controller-78f5844ddb-fvn26 secretgen-controller github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator.(*CertificateReconciler).createSecret(0xc000776a50, {0x16799b8, 0xc00089a2a0}, {{0x0, 0x0}, {0x14a0bf4, 0x9}, {0x0, 0x0, 0x0}, ...}, ...)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator/certificate_reconciler.go:119 +0x45e
secretgen-controller-78f5844ddb-fvn26 secretgen-controller github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator.(*CertificateReconciler).reconcile(0xc000776a50, {0x16799b8, 0xc00089a2a0}, 0x0)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator/certificate_reconciler.go:79 +0x29d
secretgen-controller-78f5844ddb-fvn26 secretgen-controller github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator.(*CertificateReconciler).Reconcile(0xc000776a50, {0x16799b8, 0xc00089a2a0}, {{{0xc00064f0e0, 0x138c9c0}, {0xc00064f0d0, 0xc000812340}}})
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator/certificate_reconciler.go:70 +0x395
secretgen-controller-78f5844ddb-fvn26 secretgen-controller sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler(0xc00076f040, {0x1679910, 0xc0004ac4c0}, {0x1368e00, 0xc000289000})
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:263 +0x303
secretgen-controller-78f5844ddb-fvn26 secretgen-controller sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem(0xc00076f040, {0x1679910, 0xc0004ac4c0})
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:235 +0x205
secretgen-controller-78f5844ddb-fvn26 secretgen-controller sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func1.1({0x1679910, 0xc0004ac4c0})
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:198 +0x46
secretgen-controller-78f5844ddb-fvn26 secretgen-controller k8s.io/apimachinery/pkg/util/wait.JitterUntilWithContext.func1()
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      k8s.io/[email protected]/pkg/util/wait/wait.go:185 +0x25
secretgen-controller-78f5844ddb-fvn26 secretgen-controller k8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1(0x7fa4be29dcf8)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      k8s.io/[email protected]/pkg/util/wait/wait.go:155 +0x67
secretgen-controller-78f5844ddb-fvn26 secretgen-controller k8s.io/apimachinery/pkg/util/wait.BackoffUntil(0x0, {0x16542e0, 0xc00089a120}, 0x1, 0xc0000af4a0)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      k8s.io/[email protected]/pkg/util/wait/wait.go:156 +0xb6
secretgen-controller-78f5844ddb-fvn26 secretgen-controller k8s.io/apimachinery/pkg/util/wait.JitterUntil(0x2, 0x3b9aca00, 0x0, 0x80, 0x1000000020002)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      k8s.io/[email protected]/pkg/util/wait/wait.go:133 +0x89
secretgen-controller-78f5844ddb-fvn26 secretgen-controller k8s.io/apimachinery/pkg/util/wait.JitterUntilWithContext({0x1679910, 0xc0004ac4c0}, 0xc00057a0e0, 0x0, 0x0, 0x0)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      k8s.io/[email protected]/pkg/util/wait/wait.go:185 +0x99
secretgen-controller-78f5844ddb-fvn26 secretgen-controller k8s.io/apimachinery/pkg/util/wait.UntilWithContext({0x1679910, 0xc0004ac4c0}, 0xc000614c60, 0xc00014ef68)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      k8s.io/[email protected]/pkg/util/wait/wait.go:99 +0x2b
secretgen-controller-78f5844ddb-fvn26 secretgen-controller created by sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func1
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:195 +0x4b0
secretgen-controller-78f5844ddb-fvn26 secretgen-controller panic: assignment to entry in nil map [recovered]
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      panic: assignment to entry in nil map
secretgen-controller-78f5844ddb-fvn26 secretgen-controller
secretgen-controller-78f5844ddb-fvn26 secretgen-controller goroutine 387 [running]:
secretgen-controller-78f5844ddb-fvn26 secretgen-controller k8s.io/apimachinery/pkg/util/runtime.HandleCrash({0x0, 0x0, 0xc000289000})
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      k8s.io/[email protected]/pkg/util/runtime/runtime.go:55 +0xd8
secretgen-controller-78f5844ddb-fvn26 secretgen-controller panic({0x131cda0, 0x164d9d0})
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      runtime/panic.go:1038 +0x215
secretgen-controller-78f5844ddb-fvn26 secretgen-controller github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator.GenerateInputs.Add({{0x13f7240, 0xc00049ca80}}, 0x0)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator/generate_inputs.go:23 +0x65
secretgen-controller-78f5844ddb-fvn26 secretgen-controller github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator.(*CertificateReconciler).createSecret(0xc000776a50, {0x16799b8, 0xc00089a2a0}, {{0x0, 0x0}, {0x14a0bf4, 0x9}, {0x0, 0x0, 0x0}, ...}, ...)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator/certificate_reconciler.go:119 +0x45e
secretgen-controller-78f5844ddb-fvn26 secretgen-controller github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator.(*CertificateReconciler).reconcile(0xc000776a50, {0x16799b8, 0xc00089a2a0}, 0x0)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator/certificate_reconciler.go:79 +0x29d
secretgen-controller-78f5844ddb-fvn26 secretgen-controller github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator.(*CertificateReconciler).Reconcile(0xc000776a50, {0x16799b8, 0xc00089a2a0}, {{{0xc00064f0e0, 0x138c9c0}, {0xc00064f0d0, 0xc000812340}}})
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      github.com/vmware-tanzu/carvel-secretgen-controller/pkg/generator/certificate_reconciler.go:70 +0x395
secretgen-controller-78f5844ddb-fvn26 secretgen-controller sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler(0xc00076f040, {0x1679910, 0xc0004ac4c0}, {0x1368e00, 0xc000289000})
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:263 +0x303
secretgen-controller-78f5844ddb-fvn26 secretgen-controller sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem(0xc00076f040, {0x1679910, 0xc0004ac4c0})
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:235 +0x205
secretgen-controller-78f5844ddb-fvn26 secretgen-controller sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func1.1({0x1679910, 0xc0004ac4c0})
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:198 +0x46
secretgen-controller-78f5844ddb-fvn26 secretgen-controller k8s.io/apimachinery/pkg/util/wait.JitterUntilWithContext.func1()
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      k8s.io/[email protected]/pkg/util/wait/wait.go:185 +0x25
secretgen-controller-78f5844ddb-fvn26 secretgen-controller k8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1(0x7fa4be29dcf8)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      k8s.io/[email protected]/pkg/util/wait/wait.go:155 +0x67
secretgen-controller-78f5844ddb-fvn26 secretgen-controller k8s.io/apimachinery/pkg/util/wait.BackoffUntil(0x0, {0x16542e0, 0xc00089a120}, 0x1, 0xc0000af4a0)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      k8s.io/[email protected]/pkg/util/wait/wait.go:156 +0xb6
secretgen-controller-78f5844ddb-fvn26 secretgen-controller k8s.io/apimachinery/pkg/util/wait.JitterUntil(0x2, 0x3b9aca00, 0x0, 0x80, 0x1000000020002)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      k8s.io/[email protected]/pkg/util/wait/wait.go:133 +0x89
secretgen-controller-78f5844ddb-fvn26 secretgen-controller k8s.io/apimachinery/pkg/util/wait.JitterUntilWithContext({0x1679910, 0xc0004ac4c0}, 0xc00057a0e0, 0x0, 0x0, 0x0)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      k8s.io/[email protected]/pkg/util/wait/wait.go:185 +0x99
secretgen-controller-78f5844ddb-fvn26 secretgen-controller k8s.io/apimachinery/pkg/util/wait.UntilWithContext({0x1679910, 0xc0004ac4c0}, 0xc000614c60, 0xc00014ef68)
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      k8s.io/[email protected]/pkg/util/wait/wait.go:99 +0x2b
secretgen-controller-78f5844ddb-fvn26 secretgen-controller created by sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func1
secretgen-controller-78f5844ddb-fvn26 secretgen-controller      sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:195 +0x4b0
- secretgen-controller-78f5844ddb-fvn26 › secretgen-controller

What did you expect:
[A description of what was expected]

Anything else you would like to add:
[Additional information that will assist in solving the issue.]

Environment:

• secretgen-controller version (execute kubectl get deployment -n secretgen-controller secretgen-controller -o yaml and the annotation is kbld.k14s.io/images):

kbld.k14s.io/images: |
      - origins:
        - resolved:
            tag: v0.8.0_vmware.1
            url: projects-stg.registry.vmware.com/tkg/secretgen-controller:v0.8.0_vmware.1
        - preresolved:
            url: registry.tanzu.vmware.com/tanzu-cluster-essentials/cluster-essentials-bundle@sha256:bda67d55ade826092884f49243a797e1e2a946ddbc056b37de7b8a8dedce729a
        url: registry.tanzu.vmware.com/tanzu-cluster-essentials/cluster-essentials-bundle@sha256:bda67d55ade826092884f49243a797e1e2a946ddbc056b37de7b8a8dedce729a
    secretgen-controller.carvel.dev/version: v0.8.0

• Kubernetes version (use kubectl version)

❯ kubectl version
Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.1", GitCommit:"86ec240af8cbd1b60bcc4c03c20da9b98005b92e", GitTreeState:"clean", BuildDate:"2021-12-16T11:33:37Z", GoVersion:"go1.17.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.5", GitCommit:"c285e781331a3785a7f436042c65c5641ce8a9e9", GitTreeState:"clean", BuildDate:"2022-03-24T22:06:50Z", GoVersion:"go1.17.8", Compiler:"gc", Platform:"linux/amd64"}

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.

environment variable within curly brackets are interpreted as a secret

we use a environment variable ${CREDHUB_POSTGRES_HOST} in our secret template +stringdata
see how we use it here.
https://github.com/cloudfoundry/bosh-community-stemcell-ci-infra/blob/main/config/credhub/secrets.yml#L77

a small example:

---
apiVersion: secretgen.carvel.dev/v1alpha1
kind: SecretTemplate
metadata:
  name: new-secret
spec:
  #! list of resources to read information off
  inputResources:
  - name: username-secret
    ref:
      apiVersion: v1
      kind: Secret
      name: username
  template:
    stringData:
      application.yml: |
        foo: bar
        address: "${CREDHUB_POSTGRES_HOST}"

secretgen controller is spitting out the following error

insertId: "mb8yqauemnbi5zgs"
jsonPayload: {
error: "templating stringData: unrecognized identifier CREDHUB_POSTGRES_HOST"
level: "error"
logger: "controller.sg-template"
msg: "Reconciler error"
name: "credhub-config"
namespace: "concourse"
stacktrace: "sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2
	sigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:227"
ts: 1660813208.7108898
}
labels: {5}
logName: "projects/cloud-foundry-310819/logs/stderr"
receiveTimestamp: "2022-08-18T09:00:15.000212012Z"
resource: {2}
severity: "ERROR"
timestamp: "2022-08-18T09:00:08.711057208Z"
}

see discussion at
https://kubernetes.slack.com/archives/CH8KCCKA5/p1660856228615859?thread_ts=1660813747.061909&cid=CH8KCCKA5

secretgen v0.10.3

According to the secret-export doc, secrets exported/imported across namespaces should all have the same name. There are situations where it'd be valuable to support renaming a secret in the other namespace it's referenced in.

For example: if I have a secret gershman-lets-encrypt-prod which is valid for *.cf.gershman.io, there's value in having that secret be available to multiple namespaces which might reference the secret differently--

-- I just realized halfway through writing this that I should just overlay the respective deployments to update the name of the secret reference to be whatever is chosen, so instead of having the secret be named differently across deployments in different namespaces, those deployments could just be modified to reference the same secret name.

Nevermind, submitting this issue because I already wrote up half of it & it might be of some use for searching/consideration in the future, but will immediately close it.

Thanks all 👍

Describe the problem/challenge you have
We want to ensure that the code remains compatible with the latest versions so that we do not risk falling behind and on an unsupported version (note: go supports n-1 versions).

Describe the solution you'd like
The code runs on the latest version of go.

Anything else you would like to add:

Describe the problem/challenge you have
Since we're planning to invest further into secretgen-controller, we want to ensure that we're starting at a good place from a testing perspective.

Describe the solution you'd like
We want to use this story to determine if there are any substantial gaps in testing. If gaps are detected, then we'll fill them. If it's determined that there are many gaps then we can reconvene to determine the appropriate next steps.

Anything else you would like to add:
We could also consider using this time to bring the repo's practices up to date (such as issue templates, github actions, dependabot, etc.).

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.

Make sure sercetgen-controller is production ready. This is currently undefined, but a few suggestions are:

• Using same linters as kapp-controller
• Has automated testing
• Sufficient logging
• capture some knowledge in godocs
• update to go 1.16. (currently 1.13)
• debugability
• fix up WarmUp
• rename api group?
• bump kapp-controller to use 0.5.0
• check reconciliation delay (for when kc creates placeholder secret)
• kapp will continiously reconcile out secretgen changes to image pull secrets -> fix in kapp, bump in kc
• the automated tests cover examples folder

Also, look in to other kubernetes controller best practices to ensure we follow them (time box: half a day)

Additional deliverable: A set of detailed requirements needed to deem a new controller production ready. These should be applicable generically so we can easily create/adopt new controllers using defined practices.

What steps did you take:

C:\Users\tkgadmin>kubectl apply -f https://github.com/vmware-tanzu/carvel-secretgen-controller/releases/download/v0.8.0/release.yml
customresourcedefinition.apiextensions.k8s.io/secretexports.secretgen.carvel.dev created
customresourcedefinition.apiextensions.k8s.io/secretimports.secretgen.carvel.dev created
customresourcedefinition.apiextensions.k8s.io/certificates.secretgen.k14s.io created
customresourcedefinition.apiextensions.k8s.io/passwords.secretgen.k14s.io created
customresourcedefinition.apiextensions.k8s.io/rsakeys.secretgen.k14s.io created
customresourcedefinition.apiextensions.k8s.io/sshkeys.secretgen.k14s.io created
namespace/secretgen-controller created
serviceaccount/secretgen-controller-sa created
clusterrole.rbac.authorization.k8s.io/secretgen-controller-cluster-role created
clusterrolebinding.rbac.authorization.k8s.io/secretgen-controller-cluster-role-binding created
Error from server (NotFound): error when creating "https://github.com/vmware-tanzu/carvel-secretgen-controller/releases/download/v0.8.0/release.yml": namespaces "secretgen-controller" not found

Anything else you would like to add:
Deployment worked in secretgen-controller v0.7.1

Environment:

• Windows
• secretgen-controller version: v0.8.0
• Kubernetes version: v1.22.1

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.

Describe the problem/challenge you have
I would like to export the ca.crt and tls.crt of a kubernetes.io/tls secret without exporting the private tls.key (or more generally, only export the public portion of asymmetric cryptography secrets, or an arbitrary subset of Opaque secrets).

Describe the solution you'd like
New optional fields in the SecretExport.spec (e.g. exportField, exportFields) to specify which portions of a secret to offer for export.

What steps did you take:

I went through the example for Password custom secret projection. In particular:

With custom secret projection:

apiVersion: secretgen.k14s.io/v1alpha1
kind: Password
metadata:
name: pg-password
spec:
secretTemplate:
stringData:
postgresql-pass: $(value)

would produce:

apiVersion: v1
kind: Secret
metadata:
name: pg-password
data:
postgresql-pass: xxx...

What happened:

However, reconciliation failed:

$ kubectl get passwords.secretgen.k14s.io pg-password -oyaml
apiVersion: secretgen.k14s.io/v1alpha1
kind: Password
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"secretgen.k14s.io/v1alpha1","kind":"Password","metadata":{"annotations":{},"name":"pg-password","namespace":"default"},"spec":{"secretTemplate":{"stringData":{"postgresql-pass":"$(value)"}}}}
  creationTimestamp: "2022-02-07T08:54:47Z"
  generation: 2
  name: pg-password
  namespace: default
  resourceVersion: "329229"
  selfLink: /apis/secretgen.k14s.io/v1alpha1/namespaces/default/passwords/pg-password
  uid: 74b90367-f00f-4115-a717-b759ab7f61ec
spec:
  secretTemplate:
    stringData:
      postgresql-pass: $(value)
status:
  conditions:
  - message: 'Secret "pg-password" is invalid: [data[%s][username]: Required value,
      data[%s][password]: Required value]'
    status: "True"
    type: ReconcileFailed
  friendlyDescription: 'Reconcile failed: Secret "pg-password" is invalid: [data[%s][username]:
    Required...'
  observedGeneration: 2

What did you expect:

I expected to see creation of a Secret like:

---
apiVersion: v1
kind: Secret
metadata:
  name: my-secret
stringData:
  maxmax: <crazy-generated-secret-value>

Anything else you would like to add:
[Additional information that will assist in solving the issue.]

Environment:

• secretgen-controller version (execute kubectl get deployment -n secretgen-controller secretgen-controller -o yaml and the annotation is kbld.k14s.io/images):

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "2"
    kapp.k14s.io/identity: v1;secretgen-controller/apps/Deployment/secretgen-controller;apps/v1
    kapp.k14s.io/original: '{"apiVersion":"apps/v1","kind":"Deployment","metadata":{"annotations":{"kbld.k14s.io/images":"-
      origins:\n  - local:\n      path: /Users/jkimmel/go/src/github.com/vmware-tanzu/carvel-secretgen-controller\n  -
      git:\n      dirty: false\n      remoteURL: [email protected]:vmware-tanzu/carvel-secretgen-controller.git\n      sha:
      459cddee3dea7b8cad5cc4d83f4bcf6d798c8963\n      tags:\n      - v0.7.1\n  url:
      ghcr.io/vmware-tanzu/carvel-secretgen-controller@sha256:883d6312b37597b6b65cf6ec7f2e70137a17f0c8e27211b60f3f3c3764ee7a3d\n","secretgen-controller.carvel.dev/version":"v0.7.1"},"labels":{"kapp.k14s.io/app":"1643973051553253000","kapp.k14s.io/association":"v1.1a0485fb29b825f0bdc2567860b4b9f4"},"name":"secretgen-controller","namespace":"secretgen-controller"},"spec":{"replicas":1,"revisionHistoryLimit":0,"selector":{"matchLabels":{"app":"secretgen-controller","kapp.k14s.io/app":"1643973051553253000"}},"template":{"metadata":{"labels":{"app":"secretgen-controller","kapp.k14s.io/app":"1643973051553253000","kapp.k14s.io/association":"v1.1a0485fb29b825f0bdc2567860b4b9f4"}},"spec":{"containers":[{"image":"ghcr.io/vmware-tanzu/carvel-secretgen-controller@sha256:883d6312b37597b6b65cf6ec7f2e70137a17f0c8e27211b60f3f3c3764ee7a3d","name":"secretgen-controller","resources":{"requests":{"cpu":"120m","memory":"100Mi"}},"securityContext":{"runAsGroup":2000,"runAsUser":1000}}],"securityContext":{"fsGroup":3000},"serviceAccount":"secretgen-controller-sa"}}}}'
    kapp.k14s.io/original-diff-md5: cbd70c8d709d48c3d44e2720253a1e05
    kbld.k14s.io/images: |
      - origins:
        - local:
            path: /Users/jkimmel/go/src/github.com/vmware-tanzu/carvel-secretgen-controller
        - git:
            dirty: false
            remoteURL: [email protected]:vmware-tanzu/carvel-secretgen-controller.git
            sha: 459cddee3dea7b8cad5cc4d83f4bcf6d798c8963
            tags:
            - v0.7.1
        url: ghcr.io/vmware-tanzu/carvel-secretgen-controller@sha256:883d6312b37597b6b65cf6ec7f2e70137a17f0c8e27211b60f3f3c3764ee7a3d
    secretgen-controller.carvel.dev/version: v0.7.1
  creationTimestamp: "2022-02-04T11:10:58Z"
  generation: 4
  labels:
    kapp.k14s.io/app: "1643973051553253000"
    kapp.k14s.io/association: v1.1a0485fb29b825f0bdc2567860b4b9f4
  name: secretgen-controller
  namespace: secretgen-controller

• Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.1", GitCommit:"86ec240af8cbd1b60bcc4c03c20da9b98005b92e", GitTreeState:"clean", BuildDate:"2021-12-16T11:33:37Z", GoVersion:"go1.17.5", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"19", GitVersion:"v1.19.11", GitCommit:"c6a2f08fc4378c5381dd948d9ad9d1080e3e6b33", GitTreeState:"clean", BuildDate:"2021-05-27T23:47:11Z", GoVersion:"go1.15.12", Compiler:"gc", Platform:"linux/amd64"}
WARNING: version difference between client (1.23) and server (1.19) exceeds the supported minor version skew of +/-1

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.

would make it more consistent with SecretExport name

Describe the problem/challenge you have

We use crossplane to create databases and one of the challenges we are facing is formatting Postgres DSN strings

One of the providers we used to use allowed for templating to be done with a syntax like below

    READ_DSN: {{` user={{ .UserName }} password={{ .Password }} host={{ .DatabaseHost }} port={{ .DatabasePort}} dbname={{ .DatabaseName }} sslmode=require `}}
    WRITE_DSN: {{` user={{ .UserName }} password={{ .Password }} host={{ .DatabaseHost }} port={{ .DatabasePort}} dbname={{ .DatabaseName }} sslmode=require `}

The challenge we are facing is that when we reference the secret keys (created by crossplane) they are base64 encoded

Describe the solution you'd like

If would be good to have inputResources to have a flag to decode the original secret so it can be templated as plaintext in the template part of the spec

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 would like to work on this issue.

Describe the problem/challenge you have
Use cases:

• i want to merge multiple secrets into one
• i want to rename keys within secrets
• i want to hide pieces of the secret so that it can get exported (only exporting ca.crt vs private key)

Describe the solution you'd like
introduce SecretTemplate CR that is able to read one or more secrets and produce another secret.

for example:

---
kind: SecretTemplate
metadata:
  name: combined-secret # will create combined-secret Secret
spec:
  resources:
  - secretRef:
      name: signing-key
  - secretRef:
      name: another
  ytt:
    templateContractV1:
      data.yml: |
        #@ load("@ytt:data", "data")
        metadata:
           annotations:
              foo: bar
        data:
           public.pem: #@ data.values.secrets["signing-key"].data.public
           password-value: #@ data.values.secrets.another.data.value

TBD:

• should we allow name glob on resource refs?
• should we allow referencing of configmaps?
• how does baes64 encoding play in here?

Anything else you would like to add:
[Additional information that will assist in solving the issue.]

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 would like to work on this issue.

Describe the problem/challenge you have
Similar to kapp-controller, we should add some kind of testing that verifies the arm64 version of SGC runs properly.

carvel-dev/kapp-controller#736

Describe the solution you'd like
[A clear and concise description of what you want to happen. If applicable a visual representation of the UX.]

Anything else you would like to add:
[Additional information that will assist in solving the issue.]

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 would like to work on this issue.

Describe the problem/challenge you have

currently users of SecretExport may specify toNamespace: "*". there might be namespaces in the cluster that cluster administrators would want to section off from receiving any secrets unless SecretExport explicitly specifies namespace selection.

Describe the solution you'd like
one idea in how to mark such namespaces is via annotation (on a namespace) -- secretgen.carvel.dev/excluded-from-wildcard-matching: ""

Describe the problem/challenge you have
As secretgen-controller is maturing and being promoted out of experimental, we should ensure that the repo is in a good state so that users can build trust with the tool.

Desribe the solution you'd like

• promote secretgen-controller out of the "experimental" section on the website skip this for now as we re-think our homepage layout
• promote sgc on carvel repo (GOVERNANCE). The secretgen-controller tile will point to the GitHub URL.
• ensure that secretgen-controller repo is in good shape
  • simple and focused README
  • clear "getting started" guide for users and contributors
  • design & architecture docs, if applicable
  • MAINTAINERS & GOVERNANCE files
  • SECURITY.md file
  • issue templates
  • github actions (for PRs, label mgmt)
  • dependabot
  • good first issues are labeled

Anything else you would like to add:
[Additional information that will assist in solving the issue.]

What steps did you take:
I didn't do it, actually. I was nowhere near there when it happened. It didn't even happen in a place! Several people saw me walking around outside near my residence and they're all willing to testify. I'm innocent, I swear!

What happened:
https://github.com/vmware-tanzu/carvel-secretgen-controller/runs/7909711621?check_suite_focus=true

What did you expect:
Trivy not to fail

Anything else you would like to add:
Is the issue that Neil recently fixed all the vulnerabilities, so now we're learning that there's a bug in the codepath that happens if there was nothing to report?

Environment:
github action runner

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.

Describe the problem/challenge you have

#66 Introduced the SecretTemplate API. This allows you to define arbitrary input resources that are used to generate a new Kubernetes Secret based on templating.

For a first pass, we just supported a simple jsonpath based template. However for more dynamic cases we should support a ytt templating. This would allow the entire generated secret to be templated.

Describe the solution you'd like
We should introduce an optional ytt block as an alternative to template that loads input resources as data.values. So this might look like:

---
apiVersion: secretgen.k14s.io/v1alpha1
kind: SecretTemplate
metadata:
  name: generated-secret
spec:
  serviceAccountName: my-resource-reader
  inputResources:
  - name: rds
    ref:
      apiVersion: rds.services.k8s.aws/v1alpha1
      kind: DBInstance
      name: my-rds-instance
  - name: creds
    ref:
      apiVersion: v1
      kind: Secret
      name: {.rds.masterPassword.name}
      namespace: rds-services
  ytt: | 
    #@ load("@ytt:data", "data")
    
    # Store the input resource as data values with the key being 
    # the specified reference name.
    #@ rds = data.values.rds
    #@ creds = data.values.creds
    #@ endpoint = rds.status.endpoint
    metadata:
      name: db-instance-secret
    stringData:
      type: postgresql
      database: #@ rds.spec.dbName
      port: #@ endpoint.port
      host: #@ endpoint.address
      # Example of defaulting.
      username: #@ rds.spec.masterUsername if rds.spec.masterUsername != "" else "admin"

    data:
      # Example of dynamic key loading.
      password: #@ creds.data[rds.masterUserPassword.get("key")]

Anything else you would like to add:
n/a

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 would like to work on this issue.

Describe the problem/challenge you have

#66 Introduced the SecretTemplate API. This allows you to define arbitrary input resources that are used to generate a new Kubernetes Secret based on templating.

For a first pass, to handle updates to these input resources we decided to simply periodically re-sync all input resources. However this isn't very performant or scalable.

Describe the solution you'd like

Instead of a periodic resync we should rely on watches. However SecretTemplate allows the user to provide a Service Account, this means we cannot simply have a single watch between clients and share informers. Each watch call is made for a particular identity. So any sharing mechanism would need some serious thought.

However, for cases when a Service Account is not present, SecretTemplate can only read Secrets as Input Resources. Therefore we can use watch for the non-service account secrets case.

Therefore we should do the following

• When a Service Account is not specified (Secrets only), we rely on Watches to be informed on updates.
• When a Service Account is specified, we continue to periodically resync.

Addressing the general problem can be a future enhancement.

Anything else you would like to add:
Addtional context in this PR thread

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 would like to work on this issue.

What steps did you take:

kind create cluster --image kindest/node:v1.21.1
kubectl cluster-info --context kind-kind

kapp deploy -a sg -y \
  -f https://github.com/vmware-tanzu/carvel-secretgen-controller/releases/download/v0.5.0/release.yml

kubectl create namespace src-ns
kubectl apply -f - -o yaml << EOF
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: client
  namespace: src-ns

---
apiVersion: v1
kind: Secret
metadata:
  name: client-token
  namespace: src-ns
  annotations:
    kubernetes.io/service-account.name: client
type: kubernetes.io/service-account-token

---
apiVersion: secretgen.carvel.dev/v1alpha1
kind: SecretExport
metadata:
  name: client-token
  namespace: src-ns
spec:
  toNamespace: dest-ns
EOF

kubectl create namespace dest-ns
kubectl apply -f - -o yaml << EOF
---
apiVersion: secretgen.carvel.dev/v1alpha1
kind: SecretImport
metadata:
  name: client-token
  namespace: dest-ns
spec:
  fromNamespace: src-ns
EOF

What happened:
SecretImport flaps between ReconcileSucceeded and ReconcileFailed with Condition.Message Updating imported secret: Operation cannot be fulfilled on secrets "client-token": StorageError: invalid object, Code: 4, Key: /registry/secrets/dest-ns/client-token, ResourceVersion: 0, AdditionalErrorMsg: Precondition failed: UID in precondition: 69337dc5-9141-486a-aea4-a0fad920a4f9, UID in object meta:

The empty "UID in object meta" is certainly suspicious.

What did you expect:
The secret seems to be properly created in the destination namespace, but I expected the secret to stay created! See below for terminal output (certs and tokens partially redacted but confirmed they are the same in both src and dest namespace secrets).

Anything else you would like to add:
I don't know enough about ServiceAccounts and manually replacing the auto-generated ServiceAccountToken to understand what is going on here, maybe I am doing something I should not. Most documentation seems to focus on creating a ServiceAccount and just using the auto-generated token, but since we want to share the token into another namespace, it seemed we needed to create a service account token with an explicit name that we could then export/import.

Environment:

• Kind Cluster
• Secret Generator Controller version: v0.5.0
• Kubernetes version: Client v1.22.1; Server v1.21.1

(kind-kind:default) workspace $ kubectl get secretexport client-token -n src-ns -o yaml
apiVersion: secretgen.carvel.dev/v1alpha1
kind: SecretExport
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"secretgen.carvel.dev/v1alpha1","kind":"SecretExport","metadata":{"annotations":{},"name":"client-token","namespace":"src-ns"},"spec":{"toNamespace":"dest-ns"}}
  creationTimestamp: "2021-10-17T15:08:58Z"
  generation: 1
  name: client-token
  namespace: src-ns
  resourceVersion: "76753"
  uid: ab510113-4e13-4689-97a1-9925bd742dda
spec:
  toNamespace: dest-ns
status:
  conditions:
  - status: "True"
    type: ReconcileSucceeded
  friendlyDescription: Reconcile succeeded
  observedGeneration: 1
  observedSecretResourceVersion: "76752"

(kind-kind:default) workspace $ kubectl get secret client-token -n src-ns -o yaml
apiVersion: v1
data:
  ca.crt: LS0tLS1C... ...LS0tCg==
  namespace: c3JjLW5z
  token: ZXlKaGJH... ...cFJHaTJB
kind: Secret
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Secret","metadata":{"annotations":{"kubernetes.io/service-account.name":"client"},"name":"client-token","namespace":"src-ns"},"type":"kubernetes.io/service-account-token"}
    kubernetes.io/service-account.name: client
    kubernetes.io/service-account.uid: 8fd243b4-a3dd-4ec4-9a4f-131e3ebbe0c7
  creationTimestamp: "2021-10-17T15:08:58Z"
  name: client-token
  namespace: src-ns
  resourceVersion: "76752"
  uid: 6dd50965-30ac-467a-85f5-8a55a5ad70f4
type: kubernetes.io/service-account-token



(kind-kind:default) workspace $ kubectl get secretimport client-token -n dest-ns -o yaml
apiVersion: secretgen.carvel.dev/v1alpha1
kind: SecretImport
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"secretgen.carvel.dev/v1alpha1","kind":"SecretImport","metadata":{"annotations":{},"name":"client-token","namespace":"dest-ns"},"spec":{"fromNamespace":"src-ns"}}
  creationTimestamp: "2021-10-17T15:08:58Z"
  generation: 1
  name: client-token
  namespace: dest-ns
  resourceVersion: "80211"
  uid: 92e61056-a386-453d-bb67-a9bf24c715cb
spec:
  fromNamespace: src-ns
status:
  conditions:
  - status: "True"
    type: ReconcileSucceeded
  friendlyDescription: Reconcile succeeded
  observedGeneration: 1

(kind-kind:default) workspace $ kubectl get secret client-token -n dest-ns -o yaml
apiVersion: v1
data:
  ca.crt: LS0tLS1C... ...LS0tCg==
  namespace: c3JjLW5z
  token: ZXlKaGJH... ...cFJHaTJB
kind: Secret
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"secretgen.carvel.dev/v1alpha1","kind":"SecretImport","metadata":{"annotations":{},"name":"client-token","namespace":"dest-ns"},"spec":{"fromNamespace":"src-ns"}}
    kubernetes.io/service-account.name: client
    kubernetes.io/service-account.uid: 8fd243b4-a3dd-4ec4-9a4f-131e3ebbe0c7
  creationTimestamp: "2021-10-17T15:16:33Z"
  name: client-token
  namespace: dest-ns
  ownerReferences:
  - apiVersion: secretgen.carvel.dev/v1alpha1
    blockOwnerDeletion: true
    controller: true
    kind: SecretImport
    name: client-token
    uid: 92e61056-a386-453d-bb67-a9bf24c715cb
  resourceVersion: "90285"
  uid: fc933513-8571-44ff-a666-1f38ed4d48b4
type: kubernetes.io/service-account-token

(kind-kind:default) workspace $ kubectl get secretimport client-token -n dest-ns -o yaml
apiVersion: secretgen.carvel.dev/v1alpha1
kind: SecretImport
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"secretgen.carvel.dev/v1alpha1","kind":"SecretImport","metadata":{"annotations":{},"name":"client-token","namespace":"dest-ns"},"spec":{"fromNamespace":"src-ns"}}
  creationTimestamp: "2021-10-17T15:08:58Z"
  generation: 1
  name: client-token
  namespace: dest-ns
  resourceVersion: "80291"
  uid: 92e61056-a386-453d-bb67-a9bf24c715cb
spec:
  fromNamespace: src-ns
status:
  conditions:
  - message: 'Updating imported secret: Operation cannot be fulfilled on secrets "client-token":
      StorageError: invalid object, Code: 4, Key: /registry/secrets/dest-ns/client-token,
      ResourceVersion: 0, AdditionalErrorMsg: Precondition failed: UID in precondition:
      69337dc5-9141-486a-aea4-a0fad920a4f9, UID in object meta: '
    status: "True"
    type: ReconcileFailed
  friendlyDescription: 'Reconcile failed: Updating imported secret: Operation cannot
    be fulfilled on sec...'
  observedGeneration: 1

(kind-kind:default) workspace $ kubectl get secret client-token -n dest-ns -o yaml
Error from server (NotFound): secrets "client-token" not found

Additionally, the error from the secretgen-controller logs:
{"level":"error","ts":1634525504.5472927,"logger":"controller-runtime.manager.controller.sg-secimp","msg":"Reconciler error","name":"client-token","namespace":"dest-ns","error":"Updating imported secret: Operation cannot be fulfilled on secrets \"client-token\": StorageError: invalid object, Code: 4, Key: /registry/secrets/dest-ns/client-token, ResourceVersion: 0, AdditionalErrorMsg: Precondition failed: UID in precondition: 1b82f350-b28b-47e0-beff-f121a5ef4ac5, UID in object meta: ","stacktrace":"github.com/go-logr/zapr.(*zapLogger).Error\n\tgithub.com/go-logr/[email protected]/zapr.go:132\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\tsigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:267\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\tsigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:235\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func1.1\n\tsigs.k8s.io/[email protected]/pkg/internal/controller/controller.go:198\nk8s.io/apimachinery/pkg/util/wait.JitterUntilWithContext.func1\n\tk8s.io/[email protected]/pkg/util/wait/wait.go:185\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil.func1\n\tk8s.io/[email protected]/pkg/util/wait/wait.go:155\nk8s.io/apimachinery/pkg/util/wait.BackoffUntil\n\tk8s.io/[email protected]/pkg/util/wait/wait.go:156\nk8s.io/apimachinery/pkg/util/wait.JitterUntil\n\tk8s.io/[email protected]/pkg/util/wait/wait.go:133\nk8s.io/apimachinery/pkg/util/wait.JitterUntilWithContext\n\tk8s.io/[email protected]/pkg/util/wait/wait.go:185\nk8s.io/apimachinery/pkg/util/wait.UntilWithContext\n\tk8s.io/[email protected]/pkg/util/wait/wait.go:99"}

Describe the problem/challenge you have
When multiple keys are defined in a Password object, the generated secrets are the same across all keys.

Here is an example:

---
apiVersion: secretgen.k14s.io/v1alpha1
kind: Password
metadata:
  name: postgresql-password
spec:
  secretTemplate:
    type: Opaque
    stringData:
      postgresql-password: $(value)
      postgresql-postgres-password: $(value)
      repmgr-password: $(value)

What is currently generated:

apiVersion: v1
data:
  postgresql-password: ZDJ1cjJiZm1keHFpb2F3cnNtZGYxMHN0YTl0Z2J1anB0cWx3aGdjbA==
  postgresql-postgres-password: ZDJ1cjJiZm1keHFpb2F3cnNtZGYxMHN0YTl0Z2J1anB0cWx3aGdjbA==
  repmgr-password: ZDJ1cjJiZm1keHFpb2F3cnNtZGYxMHN0YTl0Z2J1anB0cWx3aGdjbA==
kind: Secret
  name: postgresql-password
type: Opaque

Describe the solution you'd like
It would be fantastic, if each key in the secret would get a unique password.

Anything else you would like to add:
N/A

Thank you for your hard work!

Describe the problem/challenge you have
Currently, secretgen-controller cannot run on an ARM64 host, as there is no image[0].

Could we switch to doing multi-arch builds and produce arm64 alongside amd64?

Related issue for kapp-controller: carvel-dev/kapp-controller#573

This is needed for Tanzu Community Edition

Describe the problem/challenge you have
We'd like to ship secretgen-controller with the minimum necessary bits. We're currently using photon as our base image. Is there a better (i.e. slimmer) option?

Describe the solution you'd like
Investigate alternative options (such as distroless) and determine if we should consider making a switch. If the changes appear to be simple, feel free to make the necessary changes.

Anything else you would like to add:

• similar issue in kapp-controller: carvel-dev/kapp-controller#419

Describe the problem/challenge you have
Hello,

I've starting trying this tool today and it serves our need to synchronize secrets between namespaces.
But if we accidently delete the source secret, all the replicated secret will be deleted too.

Describe the solution you'd like
It would be nice to have a field in either SecretExport or SecretImport (preferably) which indicate to the controller to keep or delete the generated Secret on original Secret deletion.

Anything else you would like to add:
No

Best regards.

Describe the problem/challenge you have
The secretgen.k14s.io/v1alpha1/Password allows to specify the length of the generated password only. Unfortunately, external resources may ask to have other requirements such as: Your password must contain characters from three of the following categories – English uppercase letters, English lowercase letters, numbers (0-9), and non-alphanumeric characters (!, $, #, %, etc.). or Your password must be at least 8 characters and at most 128 characters

Describe the solution you'd like
Add extra properties to manage these requirements. The password crd can look like

apiVersion: secretgen.k14s.io/v1alpha2
kind: Password
metadata:
  name: my-constrained-long-user-password
spec:
  length:
      min: 8
      max: 128
  categories:
     - name: uppercase        #pre-defined category
        min: 2
     - name: lowercase        #pre-defined category + min:1 default values                                              
     - name: my-custom-set
        min: 3
        available: ['!', '$', '#', '%']

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 would like to work on this issue.

Describe the problem/challenge you have
We have multi-tenant clusters where isolation is done by rancher. The mechanism is simple, anyone is scoped in a rancher project, anyone can create new namespace and scope it in it's project scope by adding an annotation that is matching the project id. To summarize this annotation is the guarantee that this namespace will not be accessed by another tenant.
In our dev cluster, we have unpredictable new namespace that will be created for review environments and we want be able to use SecretImport in them, but the constraint in SecretExport based on the destination namespace is not sufficient to address our case.

Describe the solution you'd like
We would like be able to specify ToNamespaceAnnotations as following, instead of ToNamespace on SecretExport

kind: SecretExport
metadata:
  name: user-password
  namespace: user1
spec:
  toNamespaceAnnotations:
    projectId: my-project-id

This could also be

kind: SecretExport
metadata:
  name: user-password
  namespace: user1
spec:
  toNamespaceAnnotationKey: projectId
  toNamespaceAnnotationValue: my-project-id

Anything else you would like to add:
I can try to make a PR if this feature is welcome :-)

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 would like to work on this issue.