Open mikebryant opened 3 years ago
Hi @mikebryant, thank you for the detailed information & description of what you expect to happen. The way Config Connector works right now is that if there's a change in an immutable field, then ConfigConnector will return an error explaining that the field cannot be modified. In your scenario, the immutable field is the spec.secretData
which is where the k8s secret is. Once you update the k8s secret, you will need to recreate a SecretManagerSecretVersion
because you can't update the spec.secretData
field. One possible workaround/solution for you might be to have a simple controller recreate the SecretManagerSecretVersion
if the k8s secret is updated.
You mentioned that you were "expecting this to create a new secret version whenever the secret data changed", which might be a possible feature we can look into. I will bring this up to the team to consider this as an enhancement/feature request. In the meantime, can you provide us some more information for whether this is a nice-to-have, friction point, or blocker for you?
The way Config Connector works right now is that if there's a change in an immutable field, then ConfigConnector will return an error explaining that the field cannot be modified. In your scenario, the immutable field is the spec.secretData which is where the k8s secret is. Once you update the k8s secret, you will need to recreate a SecretManagerSecretVersion because you can't update the spec.secretData field.
This isn't quite accurate - I'm not updating the spec.secretData
field. The content in the Secret that that field points to has been changed. The reference may be immutable - but Secrets themselves are not immutable.
It's also worth noting that the SecretManagerSecretVersion doesn't have a field specifying which secret version it's supposed to create/manage - which is another pointer to the expectation of it making sure the latest version matches the data.
One possible workaround/solution for you might be to have a simple controller recreate the SecretManagerSecretVersion if the k8s secret is updated.
Hmm. This sounds tricky... Would need to know if the version the SecretManagerSecretVersion is pointing to is actually up to date with the Secret contents. Which we don't have easy access to - that's the idea of using ConfigConnector here. And the idea of deleting / creating the object with exactly the same contents to make ConfigConnector wake up feels like a super weird API interaction.
You mentioned that you were "expecting this to create a new secret version whenever the secret data changed", which might be a possible feature we can look into. I will bring this up to the team to consider this as an enhancement/feature request.
Thank you :)
In the meantime, can you provide us some more information for whether this is a nice-to-have, friction point, or blocker for you?
I guess I would classify this as a big friction point for using ConfigConnector here. The workaround controller doesn't feel like a simple thing to write
@mikebryant, thanks for clarifying further! The current behavior of Config Connector with secrets is documented here. Even though the contents in the Secret changed but the reference didn't, that will still cause Config Connector to try and reconcile the new Secret, hence, the error you're running into.
After running it by the team, it doesn't seem like we will support this use-case in the near future. It looks like you might be able to accomplish a workaround by trying out Kpt with Config Sync, which should allow you to modify resource configurations and redeploy/recreate them as necessary.
Any update on this issue? Also are there any considerations to implement the equivalent of the "kubectl replace" (https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#replace)? Which, for example, would allow for recreating the SecretManagerSecretVersion without the need for an additional controller
Curious if any updates for the initial question. Looking for a ConfigConnector approach to manage items in GCP Secret Manager based on values generated by cert-manager in k8s.
@caieo : Any update / support for secretmanagersecretversion object natively with config connector ?!
@yuwenma FYI this looks like a feature request that we might be able to handle after migrating to direct controller.
Yes, we are working on this one right now and will share more updates soon.
We also got into this exact same problem. Any estimate on when this will be available?
We also got into this exact same problem. Any estimate on when this will be available?
For sure, we are actively working on it, you can expect a change in the next 2-3 releases.
Just to share a little bit more on what to expect:
we are migrating the SecretManager Secret
and SecretVersion
resources to the direct approach, and making the entire SecretManager service more reliable and secure.
Checklist
Bug Description
SecretManagerSecretVersion doesn't handle updates
I wanted to use SecretManager to copy out a k8s secret that was being automatically generated (and updated) by cert-manager, so I used this config:
I was expecting this to create a new secret version whenever the secret data changed., but it fails
Additional Diagnostic Information
Kubernetes Cluster Version
Config Connector Version
Config Connector Mode
Log Output
Steps to Reproduce
Steps to reproduce the issue
Create a SecretManagerSecretVersion based off a Secret, wait for it to create the version, then update the Secret
YAML snippets