feat: (Hub) use kubernetes secrets to store credentials (auto-gene…#107
feat: (Hub) use kubernetes secrets to store credentials (auto-gene…#107
Conversation
…rate, user-override in values, optional existingSecret) Breaking: (Hub) Default passwords have been removed from values.yaml! When upgrading an existing installation, make sure to provide your passwords in your values override file
📝 WalkthroughWalkthroughTransitions Flame Hub and Authup charts from embedded plaintext credentials to a secrets-driven model: adds secret generation/template, helper to resolve secret name, deployment env vars switched to secretKeyRef, README updated to document secret usage, and authup adjusted to conditionally read from an existing secret. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🤖 Fix all issues with AI agents
In `@charts/flame-hub/README.md`:
- Around line 46-61: The fenced code block containing the credential key list
(lines with symbols like mysql-root-password, mysql-replication-password,
mysql-password, rabbitmq-password, redis-password, vault-dev-root-token,
minio-root-password, harbor-admin-password, grafana-admin-password,
redis-connection-string, rabbitmq-connection-string, vault-connection-string,
minio-connection-string, harbor-connection-string) needs a language specifier to
satisfy MD040; update the opening fence in README.md for that block to include a
language such as "text" (or "yaml") so it becomes ```text (or ```yaml) and leave
the content unchanged.
- Around line 14-17: Update the README to explicitly document the
secret-preservation behavior on helm upgrades: state that the chart uses the
Kubernetes `lookup` function to detect an existing secret named `flame-hub-auth`
and will retain previously generated passwords on `helm upgrade`, only
generating new values for credentials that are missing; mention that supplying
your own k8s secret or setting individual credentials still overrides this
behavior and clarify this applies to upgrades as well as initial installs.
- Around line 22-24: The README uses Helm template markers ({{ $secretName }}
and {{ .Release.Namespace }}) which won't be rendered; update the kubectl
example to use explicit placeholders (e.g. SECRET_NAME and NAMESPACE) and add a
one-line note telling users how to substitute real values or render the template
with Helm (e.g. use helm template/helm get manifests or pass the release
namespace) so consumers replace SECRET_NAME and NAMESPACE with actual values
instead of copying literal {{ $secretName }}/.Release.Namespace.
In `@charts/flame-hub/templates/credentials-secret.yaml`:
- Around line 26-53: The template reads keys from $existingSecret.data and pipes
them to b64dec (e.g., index $existingSecret.data "grafana-admin-password" |
b64dec), which will error if the key is missing; update every key lookup in the
block that sets $mysqlRootPassword, $mysqlReplicationPassword, $mysqlPassword,
$rabbitmqPassword, $redisPassword, $vaultToken, $minioRootPassword,
$harborAdminPassword, and $grafanaAdminPassword to first check hasKey
$existingSecret.data "<key>" (or a nil-safe conditional) before calling index
and b64dec so missing keys are skipped and do not panic during template
rendering. Ensure the same nil-safe pattern is applied consistently for all keys
in this conditional block.
In `@charts/flame-hub/values.yaml`:
- Around line 91-92: The values.yaml currently hardcodes a weak Vault dev root
token (devRootToken: "start123"); remove this default by setting devRootToken to
an empty string (require users to supply it), update the chart README to state
that devRootToken must be overridden for any non-local deployment, and add a
deployment-time warning (in the chart NOTES.txt or a pre-install hook) that
checks if devRootToken is still "start123" and emits a clear error or warning
instructing the user to replace it before proceeding.
- Line 72: Fix the typo in the comment string by adding a space after
"IMPORTANT:" so the line reads "IMPORTANT: If you set this, you must also update
the subchart configurations below to point to your secret!" — update the comment
text where that exact string appears in values.yaml.
In `@charts/third-party/authup/values.yaml`:
- Around line 7-14: The values file still defines hardcoded defaults for
vaultToken, redisPassword, and mysqlRootPassword; remove those defaults by
setting vaultToken, redisPassword, and mysqlRootPassword to empty strings so the
credentials-secret.yaml auto-generation runs when existingSecret is not
provided, or if you intentionally want standalone defaults, add a clear comment
next to vaultToken/redisPassword/mysqlRootPassword explaining they are explicit
standalone defaults (and why) so reviewers/users aren’t misled.
🧹 Nitpick comments (4)
charts/flame-hub/templates/credentials-secret.yaml (2)
1-11: Consider addinghelm.sh/resource-policy: keepannotation to prevent accidental secret deletion.If someone runs
helm uninstalland later reinstalls, the auto-generated passwords will be lost, breaking any persistent data stores (MySQL, Redis, etc.) that still use the old credentials. Adding this annotation preserves the secret across uninstall/reinstall cycles.Proposed annotation
metadata: name: {{ $secretName }} labels: app: {{ .Release.Name }}-flame-hub + annotations: + "helm.sh/resource-policy": keep type: Opaque
57-65: Random passwords regenerate on everyhelm template(dry-run) invocation.This is a known limitation of the
lookup+randAlphaNumpattern —lookupreturns empty duringhelm template, so every dry-run produces different passwords. This is fine for actualhelm install/upgrade(wherelookupworks), but worth documenting for users who rely onhelm templateoutput for GitOps workflows.charts/flame-hub/values.yaml (1)
64-73: Hardcoded subchartexistingSecretvalues will silently diverge fromauth.secretName.Changing
auth.secretNamewithout also updating every subchart'sexistingSecret(rabbitmq, redis, minio, mysql, grafana, harbor, authup) will cause pods to reference a non-existent secret. The comment warns about this, but it's fragile.Consider whether you could use an anchor/alias or a shared global value that subcharts read, so there's a single source of truth. For example:
global: flameHub: auth: secretName: "flame-hub-auth"Subcharts that support
globalvalue passthrough could then referenceglobal.flameHub.auth.secretNameinstead of each needing a hardcoded string. This may not be possible for all upstream charts, but it would reduce the blast radius of a rename.charts/flame-hub/README.md (1)
44-68: Secret key documentation is incomplete — missing connection-string formats.The README lists the required secret keys but doesn't document the expected format/value for the connection-string keys (
redis-connection-string,rabbitmq-connection-string,vault-connection-string,minio-connection-string,harbor-connection-string). Users creating a manualexistingSecretwon't know the expected URI format. Thekubectl create secretexample only shows password keys.Consider adding a brief note with the expected connection string formats, e.g.:
redis-connection-string: "redis://default:<password>@<release>-redis-master:6379"
| ## Credentials | ||
| > 🔐 **By default** this chart will create a new secret with random passwords. | ||
|
|
||
| create `values_local.yaml` then run `helm install hub . -f values_local.yaml` | ||
| This chart manages credentials using a Kubernetes Secret. By default, it will check for an existing secret named `flame-hub-auth`. If it does not exist, it will create a new secret with random passwords. You can override this behavior by providing your own k8s secret or by explicitly setting individual credentials in the values. |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
cat charts/flame-hub/templates/credentials-secret.yamlRepository: PrivateAIM/helm
Length of output: 4557
Document the secret preservation behavior during upgrades.
The template correctly uses the lookup function to preserve existing secret values on upgrade. However, the README documentation does not explicitly mention this behavior. While it states the chart will "check for an existing secret," it should clarify that on helm upgrade, previously generated passwords are retained and only missing credentials are newly generated. This will reduce operational confusion around upgrade safety.
🤖 Prompt for AI Agents
In `@charts/flame-hub/README.md` around lines 14 - 17, Update the README to
explicitly document the secret-preservation behavior on helm upgrades: state
that the chart uses the Kubernetes `lookup` function to detect an existing
secret named `flame-hub-auth` and will retain previously generated passwords on
`helm upgrade`, only generating new values for credentials that are missing;
mention that supplying your own k8s secret or setting individual credentials
still overrides this behavior and clarify this applies to upgrades as well as
initial installs.
| ```bash | ||
| kubectl get secret {{ $secretName }} -n {{ .Release.Namespace }} -o jsonpath='{.data.harbor-admin-password}' | base64 -d && echo | ||
| ``` |
There was a problem hiding this comment.
Bug: Helm template variables in README won't be rendered.
The kubectl example uses {{ $secretName }} and {{ .Release.Namespace }}, but README.md is not processed by the Helm template engine. Users copying this command will get literal {{ ... }} strings.
Proposed fix
-kubectl get secret {{ $secretName }} -n {{ .Release.Namespace }} -o jsonpath='{.data.harbor-admin-password}' | base64 -d && echo
+kubectl get secret flame-hub-auth -n <namespace> -o jsonpath='{.data.harbor-admin-password}' | base64 -d && echo🤖 Prompt for AI Agents
In `@charts/flame-hub/README.md` around lines 22 - 24, The README uses Helm
template markers ({{ $secretName }} and {{ .Release.Namespace }}) which won't be
rendered; update the kubectl example to use explicit placeholders (e.g.
SECRET_NAME and NAMESPACE) and add a one-line note telling users how to
substitute real values or render the template with Helm (e.g. use helm
template/helm get manifests or pass the release namespace) so consumers replace
SECRET_NAME and NAMESPACE with actual values instead of copying literal {{
$secretName }}/.Release.Namespace.
| ``` | ||
| mysql-root-password: | ||
| mysql-replication-password: | ||
| mysql-password: | ||
| rabbitmq-password: | ||
| redis-password: | ||
| vault-dev-root-token: | ||
| minio-root-password: | ||
| harbor-admin-password: | ||
| grafana-admin-password: | ||
| redis-connection-string: | ||
| rabbitmq-connection-string: | ||
| vault-connection-string: | ||
| minio-connection-string: | ||
| harbor-connection-string: | ||
| ``` |
There was a problem hiding this comment.
Add a language specifier to the fenced code block.
The static analysis tool flagged this block (MD040). Since this is a list of key names (not executable code), text or yaml would be appropriate:
-```
+```text
mysql-root-password:🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 46-46: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
In `@charts/flame-hub/README.md` around lines 46 - 61, The fenced code block
containing the credential key list (lines with symbols like mysql-root-password,
mysql-replication-password, mysql-password, rabbitmq-password, redis-password,
vault-dev-root-token, minio-root-password, harbor-admin-password,
grafana-admin-password, redis-connection-string, rabbitmq-connection-string,
vault-connection-string, minio-connection-string, harbor-connection-string)
needs a language specifier to satisfy MD040; update the opening fence in
README.md for that block to include a language such as "text" (or "yaml") so it
becomes ```text (or ```yaml) and leave the content unchanged.
| secretName: "flame-hub-auth" | ||
|
|
||
| # Advanced: Use your own secret instead of auto-generated one, takes precedence over secretName | ||
| # IMPORTANT:If you set this, you must also update the subchart configurations below to point to your secret! |
There was a problem hiding this comment.
Typo: missing space after "IMPORTANT:".
- # IMPORTANT:If you set this, you must also update the subchart configurations below to point to your secret!
+ # IMPORTANT: If you set this, you must also update the subchart configurations below to point to your secret!📝 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.
| # IMPORTANT:If you set this, you must also update the subchart configurations below to point to your secret! | |
| # IMPORTANT: If you set this, you must also update the subchart configurations below to point to your secret! |
🤖 Prompt for AI Agents
In `@charts/flame-hub/values.yaml` at line 72, Fix the typo in the comment string
by adding a space after "IMPORTANT:" so the line reads "IMPORTANT: If you set
this, you must also update the subchart configurations below to point to your
secret!" — update the comment text where that exact string appears in
values.yaml.
| # needs to be set. No option for passing a secret here. | ||
| devRootToken: "start123" |
There was a problem hiding this comment.
Vault dev root token is hardcoded with a weak default.
devRootToken: "start123" is a weak credential committed in plain text. Even though the comment acknowledges the Vault chart doesn't support secret references here, this token grants full Vault access.
Consider:
- Documenting clearly (in the README) that this must be overridden for any non-local deployment.
- Adding a check in a
NOTES.txtor pre-install hook that warns if the token is still"start123". - Alternatively, leave the value empty and require the user to set it, similar to the other credentials.
🤖 Prompt for AI Agents
In `@charts/flame-hub/values.yaml` around lines 91 - 92, The values.yaml currently
hardcodes a weak Vault dev root token (devRootToken: "start123"); remove this
default by setting devRootToken to an empty string (require users to supply it),
update the chart README to state that devRootToken must be overridden for any
non-local deployment, and add a deployment-time warning (in the chart NOTES.txt
or a pre-install hook) that checks if devRootToken is still "start123" and emits
a clear error or warning instructing the user to replace it before proceeding.
| auth: | ||
| # Use an existing secret with keys: vault-connection-string, redis-connection-string, mysql-root-password | ||
| existingSecret: "" | ||
|
|
||
| # or provide credentials in values (used when existingSecret is not set) | ||
| vaultToken: "start123" | ||
| redisPassword: "start123" | ||
| mysqlRootPassword: "start123" |
There was a problem hiding this comment.
Hardcoded default credentials remain in authup values.
The PR description states "default passwords have been removed from values.yaml," but vaultToken, redisPassword, and mysqlRootPassword still default to "start123". If the intent is to force users to supply credentials (as done in the main flame-hub/values.yaml), these should also be empty strings so that the auto-generation logic in credentials-secret.yaml kicks in. If these are intentionally kept for standalone authup usage, consider adding a comment clarifying that.
🤖 Prompt for AI Agents
In `@charts/third-party/authup/values.yaml` around lines 7 - 14, The values file
still defines hardcoded defaults for vaultToken, redisPassword, and
mysqlRootPassword; remove those defaults by setting vaultToken, redisPassword,
and mysqlRootPassword to empty strings so the credentials-secret.yaml
auto-generation runs when existingSecret is not provided, or if you
intentionally want standalone defaults, add a clear comment next to
vaultToken/redisPassword/mysqlRootPassword explaining they are explicit
standalone defaults (and why) so reviewers/users aren’t misled.
There was a problem hiding this comment.
I don't really care about authup
There was a problem hiding this comment.
@maxju, understood! I'll leave this as-is for now. If you'd like, I can open a follow-up issue to track updating the authup credentials for consistency with the main flame-hub chart. Just let me know.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@charts/flame-hub/README.md`:
- Around line 42-61: Update the README section to split the secret keys into two
clearly labeled groups: "Required password keys" (list mysql-root-password,
mysql-replication-password, mysql-password, rabbitmq-password, redis-password,
vault-dev-root-token, minio-root-password, harbor-admin-password,
grafana-admin-password) and "Derived connection string keys" (list
redis-connection-string, rabbitmq-connection-string, vault-connection-string,
minio-connection-string, harbor-connection-string) and state the behavior for
the chart options: when using secretName the chart templates will auto-generate
the connection strings from the provided password keys, but when using
existingSecret the user must include the connection string keys manually in that
secret; reference the configuration names existingSecret and secretName so
readers know which path requires manual connection strings.
In `@charts/flame-hub/templates/credentials-secret.yaml`:
- Around line 79-80: The Redis and RabbitMQ connection strings (keys
redis-connection-string and rabbitmq-connection-string) omit explicit ports;
update the printf templates to append :6379 for Redis and :5672 for RabbitMQ so
clients don't rely on defaults—modify the Redis line that builds
"redis://default:%s@%s-redis-master" to
"redis://default:%s@%s-redis-master:6379" (keeping $redisPassword and
.Release.Name) and modify the RabbitMQ line that builds
"amqp://%s:%s@%s-rabbitmq" to "amqp://%s:%s@%s-rabbitmq:5672" (keeping
.Values.rabbitmq.auth.username and $rabbitmqPassword and .Release.Name).
🧹 Nitpick comments (3)
charts/flame-hub/templates/credentials-secret.yaml (2)
5-11: Consider adding ahelm.sh/resource-policy: keepannotation to prevent accidental secret deletion.If a user runs
helm uninstall, this secret (containing all generated passwords) will be deleted along with the release. Since the passwords are used by stateful services (MySQL, Redis, RabbitMQ, etc.) whose data persists in PVCs, the credentials would be lost while the data remains — making recovery difficult.Suggested fix
metadata: name: {{ $secretName }} labels: app: {{ .Release.Name }}-flame-hub + annotations: + "helm.sh/resource-policy": keep type: Opaque
1-3: Use theflameHub.effectiveSecretNamehelper for consistency with deployment templates.Line 2 directly references
.Values.auth.secretName, but all deployment templates use theflameHub.effectiveSecretNamehelper to resolve the secret name. Although this template is guarded byif not .Values.auth.existingSecret(making the direct reference functionally equivalent to the helper in practice), using the helper would ensure consistency across the chart and reduce duplication of the secret name resolution logic:Suggested change
-{{- $secretName := .Values.auth.secretName }} +{{- $secretName := include "flameHub.effectiveSecretName" . }}charts/flame-hub/README.md (1)
70-97: Minimal configuration code block is missing a language specifier.Line 74 uses a bare
```fence. Addyamlfor consistent formatting and to satisfy linting:-``` +```yaml global:
| ### Creating the secret | ||
|
|
||
| The chart requires a secret with the following keys: | ||
|
|
||
| ``` | ||
| mysql-root-password: | ||
| mysql-replication-password: | ||
| mysql-password: | ||
| rabbitmq-password: | ||
| redis-password: | ||
| vault-dev-root-token: | ||
| minio-root-password: | ||
| harbor-admin-password: | ||
| grafana-admin-password: | ||
| redis-connection-string: | ||
| rabbitmq-connection-string: | ||
| vault-connection-string: | ||
| minio-connection-string: | ||
| harbor-connection-string: | ||
| ``` |
There was a problem hiding this comment.
Clarify which keys are required for existingSecret vs auto-generated.
The section says "The chart requires a secret with the following keys" and lists both individual passwords and connection strings. However, connection strings (Lines 56-61) are auto-generated from passwords in the template. For users providing an existingSecret, it's unclear whether they must manually construct all connection strings or if only the password keys are needed.
Consider splitting into two groups: required password keys (that users must provide) and derived connection strings (auto-generated when using secretName, must be manually provided when using existingSecret).
🧰 Tools
🪛 markdownlint-cli2 (0.20.0)
[warning] 46-46: Fenced code blocks should have a language specified
(MD040, fenced-code-language)
🤖 Prompt for AI Agents
In `@charts/flame-hub/README.md` around lines 42 - 61, Update the README section
to split the secret keys into two clearly labeled groups: "Required password
keys" (list mysql-root-password, mysql-replication-password, mysql-password,
rabbitmq-password, redis-password, vault-dev-root-token, minio-root-password,
harbor-admin-password, grafana-admin-password) and "Derived connection string
keys" (list redis-connection-string, rabbitmq-connection-string,
vault-connection-string, minio-connection-string, harbor-connection-string) and
state the behavior for the chart options: when using secretName the chart
templates will auto-generate the connection strings from the provided password
keys, but when using existingSecret the user must include the connection string
keys manually in that secret; reference the configuration names existingSecret
and secretName so readers know which path requires manual connection strings.
| redis-connection-string: {{ printf "redis://default:%s@%s-redis-master" $redisPassword .Release.Name | quote }} | ||
| rabbitmq-connection-string: {{ printf "amqp://%s:%s@%s-rabbitmq" .Values.rabbitmq.auth.username $rabbitmqPassword .Release.Name | quote }} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Check how these connection strings are consumed to verify port requirements
echo "=== Redis connection string usage ==="
rg -n 'redis-connection-string' charts/flame-hub/
echo ""
echo "=== RabbitMQ connection string usage ==="
rg -n 'rabbitmq-connection-string' charts/flame-hub/
echo ""
echo "=== Check Redis/RabbitMQ service port definitions in values ==="
rg -n -A3 'port:' charts/flame-hub/values.yaml | head -50
echo ""
echo "=== Check Helm chart structure ==="
find charts/flame-hub -type f -name "*.yaml" -o -name "*.yml" | head -20Repository: PrivateAIM/helm
Length of output: 2997
🏁 Script executed:
#!/bin/bash
echo "=== Check Chart.yaml for dependencies ==="
cat charts/flame-hub/Chart.yaml
echo ""
echo "=== Check values.yaml for Redis and RabbitMQ config ==="
rg -n 'redis:|rabbitmq:' charts/flame-hub/values.yaml -A 10
echo ""
echo "=== Search for Redis service definition ==="
find charts/flame-hub -name "*.yaml" -exec grep -l "redis" {} \; 2>/dev/null | xargs rg -l 'kind: Service' 2>/dev/null
echo ""
echo "=== Check for any service definitions in redis/rabbitmq directories ==="
find charts/flame-hub -type d \( -name redis -o -name rabbitmq \) 2>/dev/nullRepository: PrivateAIM/helm
Length of output: 3021
🏁 Script executed:
#!/bin/bash
echo "=== Full Redis section in values.yaml ==="
rg -n 'redis:' charts/flame-hub/values.yaml -A 30 | head -50
echo ""
echo "=== Full RabbitMQ section in values.yaml ==="
rg -n 'rabbitmq:' charts/flame-hub/values.yaml -A 30 | head -50
echo ""
echo "=== Check README for port information ==="
cat charts/flame-hub/README.md | grep -i 'port\|redis\|rabbitmq' -A 2 -B 2 | head -40Repository: PrivateAIM/helm
Length of output: 2804
🏁 Script executed:
#!/bin/bash
echo "=== Check how redis-connection-string is used in deployments ==="
rg -n 'redis-connection-string' charts/flame-hub/templates/server-core/deployment.yaml -B 5 -A 5
echo ""
echo "=== Check for REDIS_PORT or similar env vars ==="
rg -n 'REDIS.*PORT|RABBITMQ.*PORT' charts/flame-hub/templates/ -r '$0'
echo ""
echo "=== Check full credentials secret ==="
sed -n '75,85p' charts/flame-hub/templates/credentials-secret.yamlRepository: PrivateAIM/helm
Length of output: 1613
🏁 Script executed:
#!/bin/bash
echo "=== Check service definitions for Redis and RabbitMQ ==="
find charts/flame-hub/templates -name "*service*" -exec grep -l "redis\|rabbitmq" {} \;
echo ""
echo "=== Check all service definitions in the chart ==="
find charts/flame-hub/templates -name "*service*" -type f
echo ""
echo "=== Look for any port configurations in deployment manifests ==="
rg -n 'port:' charts/flame-hub/templates/server-core/deployment.yaml
echo ""
echo "=== Check if Bitnami sub-charts might override service ports ==="
rg -n 'service:' charts/flame-hub/values.yaml -A 5 | head -30Repository: PrivateAIM/helm
Length of output: 1190
🌐 Web query:
Bitnami Redis Helm chart 22.0.6 default service port
💡 Result:
In bitnami/redis Helm chart v22.0.6, the default Redis Service port is 6379/TCP (values key: master.service.ports.redis: 6379, and likewise for replicas). [1][2]
🌐 Web query:
Bitnami RabbitMQ Helm chart 16.0.14 default service port AMQP
💡 Result:
In the Bitnami RabbitMQ Helm chart v16.0.14, the default AMQP Kubernetes Service port is 5672 (configured via service.ports.amqp). [1]
AMQP TLS (if enabled) defaults to 5671 via service.ports.amqpTls. [1]
Sources
- Bitnami RabbitMQ chart parameters (“Exposure parameters”:
service.ports.amqp: 5672,service.ports.amqpTls: 5671). [1]
Add explicit port numbers to Redis and RabbitMQ connection strings for consistency and portability.
Lines 79–80 omit port numbers: redis://default:...@<release>-redis-master and amqp://...@<release>-rabbitmq. While these default to 6379 and 5672 respectively per the Bitnami charts, not all client libraries infer ports reliably. For consistency (MinIO and Vault in the same file include explicit ports) and to ensure portable client compatibility, add explicit ports:
Suggested fix
- redis-connection-string: {{ printf "redis://default:%s@%s-redis-master" $redisPassword .Release.Name | quote }}
- rabbitmq-connection-string: {{ printf "amqp://%s:%s@%s-rabbitmq" .Values.rabbitmq.auth.username $rabbitmqPassword .Release.Name | quote }}
+ redis-connection-string: {{ printf "redis://default:%s@%s-redis-master:6379" $redisPassword .Release.Name | quote }}
+ rabbitmq-connection-string: {{ printf "amqp://%s:%s@%s-rabbitmq:5672" .Values.rabbitmq.auth.username $rabbitmqPassword .Release.Name | quote }}📝 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.
| redis-connection-string: {{ printf "redis://default:%s@%s-redis-master" $redisPassword .Release.Name | quote }} | |
| rabbitmq-connection-string: {{ printf "amqp://%s:%s@%s-rabbitmq" .Values.rabbitmq.auth.username $rabbitmqPassword .Release.Name | quote }} | |
| redis-connection-string: {{ printf "redis://default:%s@%s-redis-master:6379" $redisPassword .Release.Name | quote }} | |
| rabbitmq-connection-string: {{ printf "amqp://%s:%s@%s-rabbitmq:5672" .Values.rabbitmq.auth.username $rabbitmqPassword .Release.Name | quote }} |
🧰 Tools
🪛 Checkov (3.2.334)
[medium] 79-80: Basic Auth Credentials
(CKV_SECRET_4)
🤖 Prompt for AI Agents
In `@charts/flame-hub/templates/credentials-secret.yaml` around lines 79 - 80, The
Redis and RabbitMQ connection strings (keys redis-connection-string and
rabbitmq-connection-string) omit explicit ports; update the printf templates to
append :6379 for Redis and :5672 for RabbitMQ so clients don't rely on
defaults—modify the Redis line that builds "redis://default:%s@%s-redis-master"
to "redis://default:%s@%s-redis-master:6379" (keeping $redisPassword and
.Release.Name) and modify the RabbitMQ line that builds
"amqp://%s:%s@%s-rabbitmq" to "amqp://%s:%s@%s-rabbitmq:5672" (keeping
.Values.rabbitmq.auth.username and $rabbitmqPassword and .Release.Name).
There was a problem hiding this comment.
@maxju das könnten wir uns auch überlegen, explizite port nummern zu verwenden, auch wenn das bisher nicht der fall war.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
tada5hi
changed the title
2 participants
…rate, user-override in values, optional existingSecret)
Breaking: (Hub) Default passwords have been removed from values.yaml! When upgrading an existing installation, make sure to provide your passwords in your values override file
PR for coderabbit
#106
Summary by CodeRabbit
New Features
Documentation