* feat: implement a cluster-wide generator
Signed-off-by: Gergely Brautigam <182850+Skarlso@users.noreply.github.com>
* remove unneeded function
Signed-off-by: Gergely Brautigam <182850+Skarlso@users.noreply.github.com>
* check diff run output
Signed-off-by: Gergely Brautigam <182850+Skarlso@users.noreply.github.com>
* alternative implementation of the Generator approach using specs only
Signed-off-by: Gergely Brautigam <182850+Skarlso@users.noreply.github.com>
* refactor the extracting code
Signed-off-by: Gergely Brautigam <182850+Skarlso@users.noreply.github.com>
* slight modification to the naming of the spec from generatorSpec to simply generator
Signed-off-by: Gergely Brautigam <182850+Skarlso@users.noreply.github.com>
* write a unit test for the generator and register it in the scheme
Signed-off-by: Gergely Brautigam <182850+Skarlso@users.noreply.github.com>
* add documentation for the cluster generator
Signed-off-by: Gergely Brautigam <182850+Skarlso@users.noreply.github.com>
---------
Signed-off-by: Gergely Brautigam <182850+Skarlso@users.noreply.github.com>
* Make CRD categories useful
* one category for all ES objects.
* one only for generators
* add missing controller label on CRDs
* fix UUID description (was referring to password)
Signed-off-by: Gabi Davar <grizzly.nyo@gmail.com>
* missing update
Signed-off-by: Gabi Davar <grizzly.nyo@gmail.com>
---------
Signed-off-by: Gabi Davar <grizzly.nyo@gmail.com>
* feat: Add component labels to custom resource definitions
Prerequisite for restricting the CRDs cached by Informer
Signed-off-by: Tsubasa Nagasawa <toversus2357@gmail.com>
* feat(certcontroller): Allow restricting CRDs and Webhook configs in Informer cache
The certcontroller watches CRDs and Webhook configurations, and
manages CA certificates for conversion webhooks of CRDs and Webhook
configurations. Some clusters have a large number of CRDs and Webhook
configurations installed. Additionally, some CRDs have large object sizes.
Currently, the certcontroller holds all CRDs and Webhook configurations
in the Informer cache. Since this includes CRDs not managed by the
certcontroller for CA certificates, memory usage tends to be high.
This PR adds a label to the CRDs and configures the Informer cache to hold
only the CRDs and Webhook configurations restricted by the label selector.
It assumes that the CRDs have a label. Depending on how the External Secrets
Operator is managed, it may be possible to update the External Secrets
Operator without updating the CRDs, so as a precaution, it can be turned
on/off via a startup option. It is disabled by default.
Signed-off-by: Tsubasa Nagasawa <toversus2357@gmail.com>
---------
Signed-off-by: Tsubasa Nagasawa <toversus2357@gmail.com>
fix: deprecate sourceRef.generatorRef from .data[]
A generator is supposed to be used via .dataFrom[]. Usage in .data[]
is not implemented and doesn't make sense, see #2720.
This commit splits the SourceRef into two types:
- one that only defines a secretStoreRef
- one that allows to define either secretStoreRef or generatorRef
The former is used in .data[] and the latter is used in .dataFrom[].
The Deprecated field is going to be removed with v1.
Signed-off-by: Moritz Johner <beller.moritz@googlemail.com>
* chore: update dependencies
Signed-off-by: Moritz Johner <beller.moritz@googlemail.com>
* chore: get rid of argo dependency to be independent of their k8s
versioning
Signed-off-by: Moritz Johner <beller.moritz@googlemail.com>
---------
Signed-off-by: Moritz Johner <beller.moritz@googlemail.com>
The Service Binding for Kubernetes project (servicebinding.io) is a spec
to make it easier for workloads to consume services. At runtime, the
ServiceBinding resource references a service resources and workload
resource to connect to the service. The Secret for a service is
projected into a workload resource at a well known path.
Services can advertise the name of the Secret representing the service
on it's status at `.status.binding.name`. Hosting the name of a Secret
at this location is the Provisioned Service duck type. It has the effect
of decoupling the logical consumption of a service from the physical
Secret holding state.
Using ServiceBindings with ExternalSecrets today requires the user to
directly know and reference the Secret created by the ExternalSecret as
the service reference. This PR adds the name of the Secret to the status
of the ExternalSecret at a well known location where it is be discovered
by a ServiceBinding. With this change, user can reference an
ExternalSecret from a ServiceBinding.
A ClusterRole is also added with a well known label for the
ServiceBinding controller to have permission to watch ExternalSecrets
and read the binding Secret.
ClusterExternalSecret was not modified as ServiceBindings are limited to
the scope of a single namespace.
Signed-off-by: Scott Andrews <andrewssc@vmware.com>
