K8s labels annotations

[eduardogr]

Status

READY

Migrations

Yes, Migrating from apiextensions.k8s.io/v1beta1 to apiextensions.k8s.io/v1

Description

• Resolving conflicts on PR #64
  • Populating annotations and labels from secret definition to the created secret
  • Thanks to @stevendborrelli
• Upgrading apiextensions.k8s.io/v1beta1 to apiextensions.k8s.io/v1

List of fixes # (issue)

• fix #71
• fix #62

Type of change

• [X] New feature (non-breaking change which adds functionality)
• [X] This change requires a documentation update

How Has This Been Tested?

with secrets-manager tests

Checklist:

• [X] My code follows the style guidelines of this project
• [X] I have performed a self-review of my own code
• [X] I have commented my code, particularly in hard-to-understand areas
• [X] I have made corresponding changes to the documentation
• [X] My changes generate no new warnings
• [X] I have added tests that prove my fix is effective or that my feature works
• [X] New and existing unit tests pass locally with my changes
• [X] Any dependent changes have been merged and published in downstream modules

[eduardogr]

@stevendborrelli i have here your original commits.

After your commits i've added some refactor and a fix for the test you've added. Are you Ok with this?

Thanks a lot for your changes.

[stevendborrelli]

Looks good to me! Thanks for fixing the merge conflict.

[eduardogr]

Thanks a lot @stevendborrelli :)

[raelga]

Thanks for implementing this!

We have been testing it and we faced a couple of issues. The first one is the usage of the v1 without updating the schema nor the controller toolchain (discussed here.

Regarding this feature implementation using metadata propagation, for our particular use case, it leads to an undesired behaviour that we didn't expected.

In some scenarios, labels are used to determine ownership of resources, especially when they are managed from outside the cluster. For example, some GitOps operators, like ArgoCD, use labels to identify what resources are part of a particular ArgoCD application. Propagating the labels to the resources created by the SecretDefinition instance will transfer the ownership of the Secrets created to ArgoCD.

When the SecretDefinition, created by the GitOps operator, propagates the labels, it adds metadata to the Secret resource that will end up with ArgoCD taking the "ownership" of the resource. In a GitOps scenario, that leads to the deletion of the resources, as is not present in the repository. That triggers the recreation of the secret by the secrets-manager operator, and the loop goes on. Using proper ownerReferences is not viable as in multi-cluster scenarios, the GitOps operator manage the resources from an external cluster. This is one of the scenarios that we found, put probably there are other scenarios where this propagation may lead to an undesired behaviour.