Contrary to documentation, operator accepts AWSSecret with no VersionId

[datacticapertti]

The README says "Note that aws-secret-operator intentionally disallow omitting VersionId". However, if one creates a manifest with no VersionId, it is accepted. The resulting behavior is that the secret is updated at every poll cycle.

[ecout]

Well, the Go AWS SDK API does mention this:
https://docs.aws.amazon.com/sdk-for-go/api/service/secretsmanager/#GetSecretValueInput

// Specifies the unique identifier of the version of the secret that you want
// to retrieve. If you specify this parameter then don't specify VersionStage.
// If you don't specify either a VersionStage or VersionId then the default
// is to perform the operation on the version with the VersionStage value of
// AWSCURRENT.

So it needs to be checked at the operator level indeed since the SDK will always use latest by default.
This is the starting point: https://github.com/mumoshu/aws-secret-operator/blob/master/pkg/controller/awssecret/awssecret_controller.go

This the original commit:
b6b1f96#diff-91ff3926f7c7983bb4a56689f631e6c9

[ecout]

@datacticapertti Did you use the correct image name for the deployment?
spec:
serviceAccountName: aws-secret-operator
containers:
- name: aws-secret-operator
# Replace this with the built image name
image: mumoshu/aws-secret-operator:v0.1.0
ports:
- containerPort: 60000
name: metrics

The latest build is 0.2.4:
https://github.com/mumoshu/aws-secret-operator/blob/master/Makefile

[datacticapertti]

We get aws-secret-operator in our cluster courtesy of another team so I'm not 100% sure. The deployment's creation date is 02 Jan, so before I filed the bug, and the image is aws-secret-operator:0.2.4. There does not seem to be a last modification timestamp in the deployment so hard to say for sure, but I would be surprised if the version would have been more than a couple of versions behind.

[ecout]

@datacticapertti FYI, I had to BUILD and Push 0.2.4 to my own ECR Repository to get it to work. There's no image with tag v0.2.4 in the repository listed in the documentation or the K8s deployment.yaml manifest.

I will test with this build and let you know.

[ecout]

This manifest:

apiVersion: mumoshu.github.io/v1alpha1
kind: AWSSecret
metadata:
  name: test.secrets
spec:
  stringDataFrom:
    secretsManagerSecretRef:
      secretId: test/secrets

triggers this log:

{"level":"info","ts":1584729207.022961,"logger":"controller_awssecret","caller":"awssecret/awssecret_controller.go:115","msg":"Secret does not exist, Creating a new Secret","Request.Namespace":"test","Request.Name":"test.secrets","desired.Namespace":"test","desired.Name":"test.secrets"}
{"level":"info","ts":1584729207.032896,"logger":"controller_awssecret","caller":"awssecret/awssecret_controller.go:122","msg":"Secret Created successfully, RequeueAfter 5 minutes","Request.Namespace":"test","Request.Name":"test.secrets"}

And then after the secret is updated

{"level":"info","ts":1584730183.1377544,"logger":"controller_awssecret","caller":"awssecret/awssecret_controller.go:130","msg":"versionId changed, Updating the Secret","Request.Namespace":"test","Request.Name":"test.secrets","desired.Namespace":"test","desired.Name":"test.secrets"}
{"level":"info","ts":1584730183.1440582,"logger":"controller_awssecret","caller":"awssecret/awssecret_controller.go:137","msg":"Secret Updated successfully, RequeueAfter 5 minutes","Request.Namespace":"test","Request.Name":"test.secrets"}

So we can say we've confirmed what you've reported here. In my use case this is a feature, rather than a bug. If you look at the AWS GO SDK Documentation it states clearly that if you don't specify neither the version ID nor the stage (BTW, only two versions are stored at any given time: LATEST and PREVIOUS) it will always pull the latest. This is EXACTLY what I'm looking for in a Configuration Manager for K8s. The data is updated independently but it still can be version controlled with a GUID.

[datacticapertti]

@ecout our image comes from a private ECR as well, and it was built from sources by our cloud support team. I agree that the behavior is quite reasonable, and in some use cases even desirable. My proposed fix would be just to document the behavior and be happy.

[ecout]

was built from sources by our cloud support team. I agree that the behavior is quite reasonable, and in some use cases even desirable. My proposed fix would be just to document the behavior and be happy.

+1 (y)

[ecout]

@datacticapertti
master...ecout:patch-2

Pull request created.