Version 0.4.0 not working

[gagarinfan]

Hi! I've been using your operator (which is great and very useful) version 0.3.3 and after change to 0.4.0 seems that it has stopped working both for stringDataFrom and dataFrom options. Latest version has support for base64 secrets (https://github.com/mumoshu/aws-secret-operator/pull/43) which I'd like to use.

Steps to reproduce (example for stringDataFrom option):

• EKS version 1.20
• create secret in AWS Secrets Manager. In my case it's debug-secret with Secret Key: key and Secret Value: value
• create AWSSecret object, for example:

apiVersion: mumoshu.github.io/v1alpha1
kind: AWSSecret
metadata:
  name: debug-secret
spec:
  stringDataFrom:
    secretsManagerSecretRef:
      secretId: debug-secret

• aws-secret-operator creates opaque secret debug-secret with empty data field (I've deleted irrelevant lines):

kind: Secret
apiVersion: v1
metadata:
  name: debug-secret
  namespace: debug
type: Opaque
data: {}

operator logs

{"level":"info","ts":1624874936.1018052,"logger":"controller_awssecret","msg":"Secret does not exist, Creating a new Secret","Request.Namespace":"debug","Request.Name":"debug-secret","desired.Namespace":"debug","desired.Name":"debug-secret"}
{"level":"info","ts":1624874936.1154666,"logger":"controller_awssecret","msg":"Secret Created successfully, RequeueAfter 5 minutes","Request.Namespace":"debug","Request.Name":"debug-secret"}

I would be grateful for help

[mumoshu]

Thanks for reporting! Unfortunately, this has never reproduced in my own environment. If anyone can provide me successful reproduction steps, it would be more than welcome.

[hhamalai]

We noticed the same behavior when updating from 0.3.3 to 0.5.2. Apparently AWSSecrets without versionId cause the secret update process silently to "fail" here https://github.com/mumoshu/aws-secret-operator/blob/main/controllers/awssecret_controller.go#L146:L182

VersionId is required given the instructions on readme and the open API schema, but aws-secret-operator won't output errors even if it's missing, and empty secret object is created, which is what I assume happened with @gagarinfan

[mumoshu]

@hhamalai Ah! Thank you so much for pointing it out. It does seem like I have unintentionally broken the existing "undocumented" behavior.

Yes, my intention was always to force providing versionId, so that folks would never try to use it to "auto-update" the secret which doesn't usually trigger e.g. a rolling-update of dependent k8s deployments/pods.

I'm very unsure what's the "correct" way forward. Your comment is welcomed.

For me- I'm slightly inclined to make VersionId optional officially, making it a documented behavior, so that folks can actually use it to auto-update secrets.

Almost certainly the updated documentation should suggest combining the operator with something like reloader to propagate changes down to the consumers of the secrets. WDYT?

[henkka]

Yes, my intention was always to force providing versionId, so that folks would never try to use it to "auto-update" the secret which doesn't usually trigger e.g. a rolling-update of dependent k8s deployments/pods.

FWIW I think that's a valid approach, this could be enforced by modifying versionId (and secretId) to be required fields in the schema as well, so the Kubernetes API server would enforce the intention through validation.

diff --git a/deploy/crds/mumoshu.github.io_awssecrets.yaml b/deploy/crds/mumoshu.github.io_awssecrets.yaml
index fb69ea7..5f36453 100644
--- a/deploy/crds/mumoshu.github.io_awssecrets.yaml
+++ b/deploy/crds/mumoshu.github.io_awssecrets.yaml
@@ -41,6 +41,7 @@ spec:
                   encoded using base64.
                 properties:
                   secretsManagerSecretRef:
+                    required: ["secretId", "versionId"]
                     description: SecretsManagerSecretRef defines from which SecretsManager
                       Secret the Kubernetes secret is built See https://docs.aws.amazon.com/secretsmanager/latest/userguide/terms-concepts.html
                       for the concepts
@@ -71,6 +72,7 @@ spec:
                   and allows you to provide secret data as unencoded strings.
                 properties:
                   secretsManagerSecretRef:
+                    required: ["secretId", "versionId"]
                     description: SecretsManagerSecretRef defines from which SecretsManager
                       Secret the Kubernetes secret is built See https://docs.aws.amazon.com/secretsmanager/latest/userguide/terms-concepts.html
                       for the concepts