Ability to provide static secret values

[kevarr]

Describe the solution you'd like

When using the SecretSync object there is currently no way to provide literal secret key/value pair alongside other key/value pairs resolved from a provider (e.g., a feature analogous to kubectl's --from-literal opt).

To address this, I would like to propose enhancing the SecretSync API to allow for the explicit definition of literal secret key/values alongside any other resolved values from a provider.

A conceptual implementation could look like:

apiVersion: secret-sync.x-k8s.io/v1alpha1
kind: SecretSync
metadata:
  name: my-secret
spec:
  serviceAccountName: my-service-account
  secretProviderClassName: my-secret-provider-class
  secretObject:
    type: Opaque
    data:
      - targetKey:  foo
        sourcePath: bar
      - targetKey: baz
        targetValue: qux

Resulting in a Secret like...

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  bar: c2VjcmV0Cg==
  baz: cXV4Cg==

This suggestion introduces a new targetValue property alongside sourcePath and targetKey, that is mutually exclusive with sourcePath.

Anything else you would like to add:

• https://github.com/kubernetes-sigs/secrets-store-sync-controller/blob/v0.0.2/api/v1alpha1/secretsync_types.go#L31
• https://github.com/kubernetes-sigs/secrets-store-sync-controller/blob/v0.0.2/pkg/util/secretutil/secret.go#L186

Environment:

• Secrets Store Sync Controller version: (use the image tag): v0.0.2
• Kubernetes version: (use kubectl version): N/A

[k8s-ci-robot]

This issue is currently awaiting triage.

If secrets-store-sync-controller contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[dargudear-google]

I am just wondering why someone will store the static values (not sensitive info) in the kubernetes secrets which is meant for sensitive information.

[kevarr]

@dargudear-google one example would be ArgoCD repository details. For instance

apiVersion: v1
kind: Secret
metadata:
  name: private-repo
  namespace: argocd
  labels:
    argocd.argoproj.io/secret-type: repository
stringData:
  type: git
  url: git@github.com:argoproj/my-private-repository.git
  sshPrivateKey: |
    -----BEGIN OPENSSH PRIVATE KEY-----
    ...
    -----END OPENSSH PRIVATE KEY-----

We would like to store the value for sshPrivateKey in a a cloud SecretsManager, buttype isn't sensitive and could be stored in the SecretSync object itself.