Priority
None
User Story
When shoot-grafter registers a Greenhouse cluster Secret via a CareInstruction, the resulting Secret can currently only carry additional labels (via additionalLabels) or have labels propagated from the Shoot (via propagateLabels). There is no equivalent mechanism for annotations.
Greenhouse uses annotations on cluster Secrets to drive several reconciliation behaviours. One specific example is the greenhouse.sap/oidc-override annotation, which instructs Greenhouse to inject OIDC credentials from a referenced Secret into the corresponding ClusterKubeconfig CRD:
annotations:
greenhouse.sap/propagate-annotations: "greenhouse.sap/oidc-override"
greenhouse.sap/oidc-override: '{"clientIDReference":{"name":"kubeconfig-oidc","key":"clientID"},"clientSecretReference":{"name":"kubeconfig-oidc","key":"clientSecret"}}'For clusters registered via static manifests in the Greenhouse repo, these annotations can be set directly. However, for clusters registered dynamically by shoot-grafter (e.g. a fleet of clusters with cluster-type: sci-k8s-persephone across multiple garden namespaces), there is currently no way to attach these annotations. This means those clusters remain out of sync — they differ on client-id and client-secret fields compared to the kubectl-registry — and the fix cannot be applied without a CRD change.
A concrete example: a Greenhouse operator has two categories of clusters:
- Cluster group A (
my-cluster-foo-1, my-cluster-foo-2, …): registered via static manifests — oidc-override annotation applied directly, fixed.
- Cluster group B (
my-cluster-bar-1, my-cluster-bar-2, …): registered dynamically by a CareInstruction — oidc-override annotation cannot be set, still broken.
Both groups need the same annotation. The only difference is how the cluster Secret is created.
Description
Add an additionalAnnotations field to CareInstructionSpec, parallel to the existing additionalLabels field. When set, the controller should apply these annotations to every cluster Secret it creates or reconciles.
Suggested spec addition:
// AdditionalAnnotations are annotations to be added to the Greenhouse cluster Secret
// created for each matched Shoot.
// +optional
AdditionalAnnotations map[string]string `json:"additionalAnnotations,omitempty"`
With this, users can configure:
spec:
additionalLabels:
greenhouse.sap/owned-by: my-support-group
additionalAnnotations:
greenhouse.sap/propagate-annotations: "greenhouse.sap/oidc-override"
greenhouse.sap/oidc-override: '{"clientIDReference":{"name":"kubeconfig-oidc","key":"clientID"},"clientSecretReference":{"name":"kubeconfig-oidc","key":"clientSecret"}}'Acceptance Criteria
Reference Issues
Related to the broader propagateLabels / additionalLabels pattern already in the spec.
Priority
None
User Story
When shoot-grafter registers a Greenhouse cluster Secret via a
CareInstruction, the resulting Secret can currently only carry additional labels (viaadditionalLabels) or have labels propagated from the Shoot (viapropagateLabels). There is no equivalent mechanism for annotations.Greenhouse uses annotations on cluster Secrets to drive several reconciliation behaviours. One specific example is the
greenhouse.sap/oidc-overrideannotation, which instructs Greenhouse to inject OIDC credentials from a referenced Secret into the correspondingClusterKubeconfigCRD:For clusters registered via static manifests in the Greenhouse repo, these annotations can be set directly. However, for clusters registered dynamically by shoot-grafter (e.g. a fleet of clusters with
cluster-type: sci-k8s-persephoneacross multiple garden namespaces), there is currently no way to attach these annotations. This means those clusters remain out of sync — they differ onclient-idandclient-secretfields compared to the kubectl-registry — and the fix cannot be applied without a CRD change.A concrete example: a Greenhouse operator has two categories of clusters:
my-cluster-foo-1,my-cluster-foo-2, …): registered via static manifests — oidc-override annotation applied directly, fixed.my-cluster-bar-1,my-cluster-bar-2, …): registered dynamically by aCareInstruction— oidc-override annotation cannot be set, still broken.Both groups need the same annotation. The only difference is how the cluster Secret is created.
Description
Add an
additionalAnnotationsfield toCareInstructionSpec, parallel to the existingadditionalLabelsfield. When set, the controller should apply these annotations to every cluster Secret it creates or reconciles.Suggested spec addition:
With this, users can configure:
Acceptance Criteria
additionalAnnotationsfield added toCareInstructionSpecadditionalAnnotationsto the cluster Secret on create and reconcileadditionalAnnotationsremoves it from the Secret on next reconcileReference Issues
Related to the broader
propagateLabels/additionalLabelspattern already in the spec.