Add blog referencing-secrets-and-configmaps-in-extension-and-controllerdeployment-helm-values - #1032
Conversation
…erdeployment-helm-values
✅ Deploy Preview for gardener-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
📝 WalkthroughWalkthroughAdds a blog post for Gardener v1.147. It documents Secret and ConfigMap references in Extension and ControllerDeployment Helm values, including syntax, validation, resolution, and deletion protection. ChangesHelm value references
Estimated code review effort: 1 (Trivial) | ~5 minutes Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@oliver-goetz: adding LGTM is restricted to approvers and reviewers in OWNERS files. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. |
Signed-off-by: Bozhidara Hristova <bozhidara.hristova@sap.com>
Signed-off-by: Bozhidara Hristova <bozhidara.hristova@sap.com>
Signed-off-by: Bozhidara Hristova <bozhidara.hristova@sap.com>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
1 similar comment
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Actionable comments posted: 4
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In
`@hugo/content/blog/2026/07/07-23-referencing-secrets-and-configmaps-in-extension-and-controllerdeployment-helm-values.md`:
- Around line 60-64: Update the resource-reference documentation near the
Extension and ControllerDeployment usage description to explicitly state that
only v1 Secret and ConfigMap resources are supported, and that Secret.data
values are base64-decoded before substitution. Preserve the existing namespace
and label requirements.
- Line 26: Revise the introductory paragraph around the inline Helm values in
Extension and ControllerDeployment to distinguish their respective cluster
storage locations and avoid claiming both are unencrypted in the runtime
cluster. Retain the point that embedding sensitive values couples credential
updates and rotation with changes to the parent resource and extension version
management, without making unsupported encryption assertions.
- Line 77: Update the finalizer reference in the documentation sentence to use
the exact identifier “gardener.cloud/reference-protection” instead of the
shortened “reference-protection,” while preserving the existing explanation.
- Around line 70-73: Clarify the validation statement so alphanumeric-only
restrictions explicitly apply to the template alias <name> and data key <key>,
not resourceRef.name. Preserve the existing admission-time validation wording
and acknowledge that referenced Kubernetes resource names may contain characters
such as dashes.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro Plus
Run ID: d547ff6e-487a-45f9-9aad-bf5d133cd54d
📒 Files selected for processing (1)
hugo/content/blog/2026/07/07-23-referencing-secrets-and-configmaps-in-extension-and-controllerdeployment-helm-values.md
| local: true | ||
| --- | ||
|
|
||
| Gardener extensions and controller deployments are configured via Helm values embedded directly in `Extension` (`operator.gardener.cloud`) and `ControllerDeployment` (`core.gardener.cloud`) objects. Until now, this meant sensitive data — credentials, certificates, environment-specific configuration — had to be stored inline in these objects. That created friction: the objects are not encrypted at rest in the runtime cluster, external secret management systems had to update the extension object itself, and credential rotation could conflict with extension version management since both touch the same object. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Qualify the cluster and encryption statement.
ControllerDeployment is stored in the virtual garden cluster, not the garden runtime cluster. Gardener also lists core.gardener.cloud/v1/ControllerDeployment among resources encrypted by default. This sentence can lead readers to make an incorrect security decision. Reword it to describe the coupling caused by inline values without claiming that both resource types are unencrypted in the runtime cluster. (github.com)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@hugo/content/blog/2026/07/07-23-referencing-secrets-and-configmaps-in-extension-and-controllerdeployment-helm-values.md`
at line 26, Revise the introductory paragraph around the inline Helm values in
Extension and ControllerDeployment to distinguish their respective cluster
storage locations and avoid claiming both are unencrypted in the runtime
cluster. Retain the point that embedding sensitive values couples credential
updates and rotation with changes to the parent resource and extension version
management, without making unsupported encryption assertions.
| For `Extension`, the references are resolved by `gardener-operator` against the garden runtime cluster and can be used in `spec.deployment.extension.values`, `spec.deployment.extension.runtimeClusterValues`, and `spec.deployment.admission.values`. | ||
|
|
||
| For `ControllerDeployment`, the references are resolved by `gardenlet` against the virtual garden cluster and can be used in `helm.values`. | ||
|
|
||
| Referenced objects must reside in the `garden` namespace and carry the label `gardener.cloud/role: resource-reference`. This label is required so that the controllers watching them can pick up changes and trigger reconciliation — meaning when a `Secret` or `ConfigMap` value changes, the extension or controller deployment is automatically reconciled with the new values. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Document the supported resource contract.
State that only Secret and ConfigMap references with apiVersion: v1 are supported. Also state that Secret.data values are base64-decoded before substitution. The current prose leaves both behaviors implicit in the example. (github.com)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@hugo/content/blog/2026/07/07-23-referencing-secrets-and-configmaps-in-extension-and-controllerdeployment-helm-values.md`
around lines 60 - 64, Update the resource-reference documentation near the
Extension and ControllerDeployment usage description to explicitly state that
only v1 Secret and ConfigMap resources are supported, and that Secret.data
values are base64-decoded before substitution. Preserve the existing namespace
and label requirements.
| - Every `{{ ... }}` expression in the values must match exactly the form `{{ .resources.<name>.data.<key> }}`. Other Go template constructs are rejected. | ||
| - The referenced `<name>` must be declared in the same object's `resources` list. Referencing an undeclared name is rejected at admission time. | ||
|
|
||
| Invalid characters in names (dashes, underscores — only alphanumeric characters are allowed) are also caught immediately. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Clarify which names must be alphanumeric.
The restriction applies to the template alias <name> and data key <key>. It does not apply to resourceRef.name. The current wording is ambiguous because the example uses a Kubernetes object name containing dashes. (github.com)
Suggested wording
-Invalid characters in names (dashes, underscores — only alphanumeric characters are allowed) are also caught immediately.
+The template alias <name> and data key <key> must contain only alphanumeric characters. The Kubernetes object name in resourceRef.name is separate.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - Every `{{ ... }}` expression in the values must match exactly the form `{{ .resources.<name>.data.<key> }}`. Other Go template constructs are rejected. | |
| - The referenced `<name>` must be declared in the same object's `resources` list. Referencing an undeclared name is rejected at admission time. | |
| Invalid characters in names (dashes, underscores — only alphanumeric characters are allowed) are also caught immediately. | |
| - Every `{{ ... }}` expression in the values must match exactly the form `{{ .resources.<name>.data.<key> }}`. Other Go template constructs are rejected. | |
| - The referenced `<name>` must be declared in the same object's `resources` list. Referencing an undeclared name is rejected at admission time. | |
| The template alias <name> and data key <key> must contain only alphanumeric characters. The Kubernetes object name in resourceRef.name is separate. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@hugo/content/blog/2026/07/07-23-referencing-secrets-and-configmaps-in-extension-and-controllerdeployment-helm-values.md`
around lines 70 - 73, Clarify the validation statement so alphanumeric-only
restrictions explicitly apply to the template alias <name> and data key <key>,
not resourceRef.name. Preserve the existing admission-time validation wording
and acknowledge that referenced Kubernetes resource names may contain characters
such as dashes.
|
|
||
| ## Reference Protection | ||
|
|
||
| A finalizer (`reference-protection`) is added to any referenced `Secret` or `ConfigMap` by the reference controller, preventing accidental deletion while the object is in use by an extension or controller deployment. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Use the full finalizer name.
The reference controller adds gardener.cloud/reference-protection, not reference-protection. Use the exact identifier so readers can inspect metadata.finalizers correctly. (github.com)
Suggested fix
-A finalizer (`reference-protection`) is added
+A finalizer (`gardener.cloud/reference-protection`) is added📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| A finalizer (`reference-protection`) is added to any referenced `Secret` or `ConfigMap` by the reference controller, preventing accidental deletion while the object is in use by an extension or controller deployment. | |
| A finalizer (`gardener.cloud/reference-protection`) is added to any referenced `Secret` or `ConfigMap` by the reference controller, preventing accidental deletion while the object is in use by an extension or controller deployment. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@hugo/content/blog/2026/07/07-23-referencing-secrets-and-configmaps-in-extension-and-controllerdeployment-helm-values.md`
at line 77, Update the finalizer reference in the documentation sentence to use
the exact identifier “gardener.cloud/reference-protection” instead of the
shortened “reference-protection,” while preserving the existing explanation.
|
@oliver-goetz, @rfranzke, I had to move the blog post to |
Purpose
@oliver-goetz This PR proposes a new blog post titled:
The purpose of the blog post is to inform the community about new Gardener features or changes (2026-07-23).
Notes to Reviewers
This blog post was generated with AI assistance from the source material listed below.
Please evaluate whether this topic is suitable for a blog post. If so, review and edit the content as needed.
If you decide the topic isn't appropriate for a blog post, feel free to close this PR and delete the branch.
Source Material
Secrets andConfigMaps inExtensionandControllerDeploymentHelm values gardener#14979Instructions for Reviewers
❌ If the blog post isn't viable
✏️ If the blog post is viable but requires editing
git clone https://github.com/gardener/documentation cd documentationgit fetch origin && git checkout blog/2026-07-23-referencing-secrets-and-configmaps-in-extension-and-controllerdeployment-helm-valueswebsite/blog/2026/07/07-23-referencing-secrets-and-configmaps-in-extension-and-controllerdeployment-helm-values.md.✅ If the blog post is ready
/lgtmto approve (required step)The documentation team will review your PR, as required by branch protection.
They will merge it once you (and any additional reviewers) have approved it.
@oliver-goetz Thank you for contributing to the Gardener blog!
Summary by CodeRabbit
SecretandConfigMapdata inExtensionandControllerDeploymentHelm values.ControllerDeploymentusage.