From fd70378fdd3290f8483b3cc40acbe663749d3212 Mon Sep 17 00:00:00 2001 From: Amber Alston Date: Fri, 22 May 2026 10:27:18 -0600 Subject: [PATCH 1/2] Document pods/exec RBAC requirement for SDK support bundle exec collectors The SDK's built-in support bundle spec uses exec collectors to call internal API endpoints, but the pods/exec RBAC requirement was not documented. Without it, app-info.json and license.yaml are silently missing from bundles. This adds an RBAC requirements section to the customizing page and a troubleshooting entry to the generating page. sc-136407 Co-Authored-By: Claude Opus 4.6 (1M context) --- docs/vendor/support-bundle-customizing.mdx | 18 +++++++++++++++ docs/vendor/support-bundle-generating.mdx | 26 +++++++++++++++++++++- 2 files changed, 43 insertions(+), 1 deletion(-) diff --git a/docs/vendor/support-bundle-customizing.mdx b/docs/vendor/support-bundle-customizing.mdx index 5172616eed..504a4d8d95 100644 --- a/docs/vendor/support-bundle-customizing.mdx +++ b/docs/vendor/support-bundle-customizing.mdx @@ -51,6 +51,24 @@ To add the default support bundle spec to a release for your application: 1. Add the chart archive to a new release. Promote the release to an internal development channel, and install the release in a development environment to test your changes. +## RBAC requirements for exec collectors {#exec-rbac} + +The Replicated SDK includes a built-in support bundle spec that uses `exec` collectors to call internal SDK API endpoints (such as `/api/v1/app/info` and `/api/v1/license/info`). These collectors retrieve application and license information that appears as `app-info.json` and `license.yaml` in the generated bundle. + +For these `exec` collectors to work, the service account running the support bundle must have `pods/exec` with the `create` verb in its RBAC Role or ClusterRole. For example: + +```yaml +- apiGroups: [""] + resources: ["pods/exec"] + verbs: ["create"] +``` + +Without this permission, the `exec` collectors fail silently. The support bundle is still generated and can be uploaded to the Vendor Portal, but `app-info.json` and `license.yaml` will be missing. The Vendor Portal displays warnings such as "No app-info file found" and "No license file found" when these files are absent. + +:::note +KOTS installations include `pods/exec` permissions in the default kotsadm Role. For Helm CLI installations, you must ensure the service account used to run `kubectl support-bundle` has this permission. +::: + ## (Recommended) Customize the default support bundle spec {#customize-the-spec} You can customize the support bundle spec by: diff --git a/docs/vendor/support-bundle-generating.mdx b/docs/vendor/support-bundle-generating.mdx index fdd8176c31..720690804d 100644 --- a/docs/vendor/support-bundle-generating.mdx +++ b/docs/vendor/support-bundle-generating.mdx @@ -23,4 +23,28 @@ Run the following command: ```bash kubectl support-bundle https://raw.githubusercontent.com/replicatedhq/troubleshoot-specs/main/in-cluster/default.yaml -``` \ No newline at end of file +``` + +## Troubleshoot + +### Support bundle is missing app-info or license data + +#### Symptom + +After uploading a support bundle to the Vendor Portal, you see warnings: "No app-info file found" or "No license file found." + +#### Cause + +The Replicated SDK's built-in support bundle spec uses `exec` collectors to retrieve application and license information from the SDK pod. If the service account running the support bundle does not have `pods/exec` permissions with the `create` verb, these collectors fail silently and the data is not included in the bundle. + +#### Solution + +Add `pods/exec` permissions to the RBAC Role or ClusterRole for the service account running the support bundle: + +```yaml +- apiGroups: [""] + resources: ["pods/exec"] + verbs: ["create"] +``` + +For more information, see [RBAC requirements for exec collectors](/vendor/support-bundle-customizing#exec-rbac). \ No newline at end of file From 3bc7ce0dacc5828fe51100c6e11b871ddcdb6ceb Mon Sep 17 00:00:00 2001 From: Amber Alston Date: Fri, 22 May 2026 11:38:39 -0600 Subject: [PATCH 2/2] Add note about Bitnami allowInsecureImages flag for proxy registry Bitnami charts reject images from non-default registries with a misleading error. Document the workaround and clarify that the flag name does not indicate insecure connections. Closes #3989 Co-Authored-By: Claude Opus 4.6 (1M context) --- docs/vendor/helm-image-registry.mdx | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/vendor/helm-image-registry.mdx b/docs/vendor/helm-image-registry.mdx index 543221cfad..77f9f5a907 100644 --- a/docs/vendor/helm-image-registry.mdx +++ b/docs/vendor/helm-image-registry.mdx @@ -34,6 +34,10 @@ To configure your application to use the proxy registry with Helm CLI installati 1. + :::note + Bitnami charts may display the error "Original containers have been substituted for unrecognized ones" when images are pulled from the Replicated proxy registry instead of the default Bitnami registry. To resolve this, set `global.security.allowInsecureImages=true` in your Helm values. Despite the name, this flag permits images from non-Bitnami registries. Your images are still pulled over HTTPS with authentication. + ::: + 1. 1.