NO-JIRA: Run 2 Vault instances in different namespaces#80405
Conversation
openshift-ci
Bot
added
the
do-not-merge/work-in-progress
|
Skipping CI for Draft Pull Request. |
WalkthroughThis PR refactors Vault install/configure scripts into parameterized functions and adds support for a secondary Vault Enterprise instance: two installs with separate CA ConfigMaps and two configure runs that create per-namespace transit keys and vault-credentials secrets. Documentation and step refs updated accordingly. ChangesVault Dual Namespace Support
🎯 3 (Moderate) | ⏱️ ~20 minutes Important Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional. ❌ Failed checks (1 error, 2 warnings)
✅ Passed checks (12 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
openshift-ci
Bot
added
the
approved
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
ci-operator/step-registry/etcd-encryption/vault-install/etcd-encryption-vault-install-commands.sh (2)
50-52: 💤 Low valueSame idempotency consideration applies to secret creation.
For consistency with the ConfigMap pattern, this could also use the apply approach:
- oc create secret generic "${VAULT_LICENSE_SECRET_NAME}" \ - --from-file=license=/var/run/vault/tests-private-account/kms-vault-license \ - -n "${ns}" + oc create secret generic "${VAULT_LICENSE_SECRET_NAME}" \ + --from-file=license=/var/run/vault/tests-private-account/kms-vault-license \ + -n "${ns}" \ + --dry-run=client -o yaml | oc apply -f -🤖 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 `@ci-operator/step-registry/etcd-encryption/vault-install/etcd-encryption-vault-install-commands.sh` around lines 50 - 52, The secret creation for VAULT_LICENSE_SECRET_NAME is not idempotent; change the oc create call to an apply-style pattern so repeated runs update or create the secret safely (e.g. generate the secret YAML with oc create secret generic "${VAULT_LICENSE_SECRET_NAME}" --from-file=license=/var/run/vault/tests-private-account/kms-vault-license --dry-run=client -o yaml | oc apply -n "${ns}" -f -) so the operation is consistent with the ConfigMap pattern and uses the same VAULT_LICENSE_SECRET_NAME and ns variables.
44-44: ⚡ Quick winNamespace creation is not idempotent—consider apply pattern for retry resilience.
If a previous run failed after creating the namespace but before completion, a retry will fail here. Using the apply pattern would make this step idempotent:
- oc create namespace "${ns}" + oc create namespace "${ns}" --dry-run=client -o yaml | oc apply -f -This aligns with the pattern already used for ConfigMap creation on lines 88-91.
🤖 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 `@ci-operator/step-registry/etcd-encryption/vault-install/etcd-encryption-vault-install-commands.sh` at line 44, The direct call oc create namespace "${ns}" is not idempotent; replace it with the apply pattern used for the ConfigMap (so retries are safe). Locate the oc create namespace "${ns}" invocation and change it to apply a Namespace manifest (e.g., construct a small YAML with apiVersion: v1, kind: Namespace, metadata.name: "${ns}" and pipe it to oc apply -f -) so the step becomes idempotent and tolerant of previous partial runs.
🤖 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
`@ci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-commands.sh`:
- Line 87: Remove the sensitive echo that prints the AppRole credential by
eliminating or redacting the line that prints ROLE_ID (the echo " - ROLE_ID:
${role_id}") in the etcd-encryption-vault-configure-commands.sh script; instead
log a non-sensitive confirmation such as " - ROLE_ID: [REDACTED]" or omit the
ROLE_ID output entirely so the role_id variable is never written to CI logs
while preserving other non-sensitive log output.
- Line 33: Quote the transit key path when calling vault write and stop leaking
secrets: change the vault write invocation to pass a quoted path like
"transit/keys/${VAULT_KMS_KEY_NAME}" (i.e. env VAULT_TOKEN="${ROOT_TOKEN}" vault
write -namespace="${VAULT_ENTERPRISE_NS}" -f
"transit/keys/${VAULT_KMS_KEY_NAME}"), and ensure any AppRole identifiers/tokens
(ROLE_ID, secret_id, ROOT_TOKEN) are not echoed or traced — disable shell xtrace
around secret usage (set +x / restore afterwards) and suppress or redirect
command output (e.g. redirect stdout/stderr or write to a secure file) so
secrets are never printed to CI logs.
---
Nitpick comments:
In
`@ci-operator/step-registry/etcd-encryption/vault-install/etcd-encryption-vault-install-commands.sh`:
- Around line 50-52: The secret creation for VAULT_LICENSE_SECRET_NAME is not
idempotent; change the oc create call to an apply-style pattern so repeated runs
update or create the secret safely (e.g. generate the secret YAML with oc create
secret generic "${VAULT_LICENSE_SECRET_NAME}"
--from-file=license=/var/run/vault/tests-private-account/kms-vault-license
--dry-run=client -o yaml | oc apply -n "${ns}" -f -) so the operation is
consistent with the ConfigMap pattern and uses the same
VAULT_LICENSE_SECRET_NAME and ns variables.
- Line 44: The direct call oc create namespace "${ns}" is not idempotent;
replace it with the apply pattern used for the ConfigMap (so retries are safe).
Locate the oc create namespace "${ns}" invocation and change it to apply a
Namespace manifest (e.g., construct a small YAML with apiVersion: v1, kind:
Namespace, metadata.name: "${ns}" and pipe it to oc apply -f -) so the step
becomes idempotent and tolerant of previous partial runs.
🪄 Autofix (Beta)
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: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 014e06bb-f032-4a2e-830f-090d4f8c52ce
📒 Files selected for processing (5)
ci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-commands.shci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-ref.yamlci-operator/step-registry/etcd-encryption/vault-install/etcd-encryption-vault-install-commands.shci-operator/step-registry/etcd-encryption/vault-install/etcd-encryption-vault-install-ref.yamlci-operator/step-registry/etcd-encryption/vault-setup/etcd-encryption-vault-setup-chain.yaml
| env VAULT_TOKEN="${ROOT_TOKEN}" vault write -namespace="${VAULT_ENTERPRISE_NS}" -f transit/keys/${VAULT_KMS_KEY_NAME} | ||
| echo "Creating transit encryption key..." | ||
| oc exec vault-0 -n "${ns}" -- \ | ||
| env VAULT_TOKEN="${ROOT_TOKEN}" vault write -namespace="${VAULT_ENTERPRISE_NS}" -f transit/keys/${VAULT_KMS_KEY_NAME} |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Verify the unquoted interpolation site in this script
rg -n 'transit/keys/\$\{VAULT_KMS_KEY_NAME\}' ci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-commands.shRepository: openshift/release
Length of output: 235
Quote the Vault transit key path argument
Line 33 passes ${VAULT_KMS_KEY_NAME} unquoted; quote the transit/keys/... path in the vault write -f command.
Suggested fix
- env VAULT_TOKEN="${ROOT_TOKEN}" vault write -namespace="${VAULT_ENTERPRISE_NS}" -f transit/keys/${VAULT_KMS_KEY_NAME}
+ env VAULT_TOKEN="${ROOT_TOKEN}" vault write -namespace="${VAULT_ENTERPRISE_NS}" -f "transit/keys/${VAULT_KMS_KEY_NAME}"Avoid leaking AppRole identifiers in logs
Ensure ROLE_ID/secret_id/tokens are not echoed to CI logs (or are protected by disabling tracing and keeping output off stdout).
📝 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.
| env VAULT_TOKEN="${ROOT_TOKEN}" vault write -namespace="${VAULT_ENTERPRISE_NS}" -f transit/keys/${VAULT_KMS_KEY_NAME} | |
| env VAULT_TOKEN="${ROOT_TOKEN}" vault write -namespace="${VAULT_ENTERPRISE_NS}" -f "transit/keys/${VAULT_KMS_KEY_NAME}" |
🧰 Tools
🪛 Shellcheck (0.11.0)
[info] 33-33: Double quote to prevent globbing and word splitting.
(SC2086)
🤖 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
`@ci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-commands.sh`
at line 33, Quote the transit key path when calling vault write and stop leaking
secrets: change the vault write invocation to pass a quoted path like
"transit/keys/${VAULT_KMS_KEY_NAME}" (i.e. env VAULT_TOKEN="${ROOT_TOKEN}" vault
write -namespace="${VAULT_ENTERPRISE_NS}" -f
"transit/keys/${VAULT_KMS_KEY_NAME}"), and ensure any AppRole identifiers/tokens
(ROLE_ID, secret_id, ROOT_TOKEN) are not echoed or traced — disable shell xtrace
around secret usage (set +x / restore afterwards) and suppress or redirect
command output (e.g. redirect stdout/stderr or write to a secure file) so
secrets are never printed to CI logs.
Source: Linters/SAST tools
ardaguclu
force-pushed
the
multiple-vault
branch
from
b0e082d to
f2fba76
Compare
ardaguclu
force-pushed
the
multiple-vault
branch
from
f2fba76 to
e3fadfa
Compare
|
/pj-rehearse |
|
@ardaguclu: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
ci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-ref.yaml (1)
34-59:⚠️ Potential issue | 🟡 Minor | ⚡ Quick winUpdate documentation to reflect dual-instance configuration.
The step documentation describes configuring "an already-installed Vault instance" (singular) and lists outputs only for the primary namespace, but the script now configures two instances—primary (
${VAULT_NAMESPACE}) and secondary (${VAULT_SECONDARY_NAMESPACE}).The configuration steps (lines 39-47) and outputs (lines 53-58) should clarify that these operations occur for both instances, and that credentials are stored in both namespaces.
📝 Suggested documentation structure
documentation: |- - Configures an already-installed Vault instance for Kubernetes KMS encryption. + Configures two already-installed Vault instances for Kubernetes KMS encryption. This step should run after etcd-encryption-vault-install. - Configuration steps: + Configuration steps (performed for both primary and secondary instances): - Creates Vault Enterprise namespace (${VAULT_ENTERPRISE_NS}) - Enables transit secret engine in ${VAULT_ENTERPRISE_NS} - - Creates transit encryption key (name: ${VAULT_KMS_KEY_NAME}) in ${VAULT_ENTERPRISE_NS} + - Creates transit encryption key in ${VAULT_ENTERPRISE_NS} - Enables AppRole authentication in ${VAULT_ENTERPRISE_NS} - Creates KMS policy with encrypt/decrypt permissions in ${VAULT_ENTERPRISE_NS} - Creates AppRole role (kms-plugin) in ${VAULT_ENTERPRISE_NS} - Retrieves AppRole credentials from ${VAULT_ENTERPRISE_NS} - Stores credentials in vault-credentials secret Prerequisites: - - Vault must be installed and pods Ready (run etcd-encryption-vault-install first) - - OpenShift cluster with vault-0 pod running in ${VAULT_NAMESPACE} + - Both Vault instances must be installed and pods Ready (run etcd-encryption-vault-install first) + - OpenShift cluster with vault-0 pods running in ${VAULT_NAMESPACE} and ${VAULT_SECONDARY_NAMESPACE} Outputs: - - Credentials stored in: vault-credentials secret (namespace: ${VAULT_NAMESPACE}) + - Credentials stored in vault-credentials secrets in both ${VAULT_NAMESPACE} and ${VAULT_SECONDARY_NAMESPACE} * role-id: AppRole role ID * secret-id: AppRole secret ID * root-token: Vault root token * unseal-key: Vault unseal key🤖 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 `@ci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-ref.yaml` around lines 34 - 59, Update the step documentation to reflect that configuration runs against two Vault instances (primary ${VAULT_NAMESPACE} and secondary ${VAULT_SECONDARY_NAMESPACE}): change the opening sentence to say "instances" not "instance", update the Configuration steps block (the list that references ${VAULT_ENTERPRISE_NS} and ${VAULT_KMS_KEY_NAME}) to state each action is performed in both namespaces (primary and secondary), and update the Outputs block to indicate vault-credentials secrets are created/stored in both namespaces (include role-id, secret-id, root-token, unseal-key for each namespace).
🤖 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
`@ci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-ref.yaml`:
- Around line 32-33: Update the explanatory sentence for the secondary transit
key so it no longer claims differing names produce distinct key material;
instead state that because configure_vault runs in separate Vault instances
(e.g., vault-0 in vault-kms vs vault-0 in vault-kms-2) their KEKs are stored
separately and cryptographically independent regardless of name, and that using
a different name from VAULT_KMS_KEY_NAME is recommended only for
clarity/organization and to avoid naming collisions; modify the text referencing
VAULT_KMS_KEY_NAME accordingly.
---
Outside diff comments:
In
`@ci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-ref.yaml`:
- Around line 34-59: Update the step documentation to reflect that configuration
runs against two Vault instances (primary ${VAULT_NAMESPACE} and secondary
${VAULT_SECONDARY_NAMESPACE}): change the opening sentence to say "instances"
not "instance", update the Configuration steps block (the list that references
${VAULT_ENTERPRISE_NS} and ${VAULT_KMS_KEY_NAME}) to state each action is
performed in both namespaces (primary and secondary), and update the Outputs
block to indicate vault-credentials secrets are created/stored in both
namespaces (include role-id, secret-id, root-token, unseal-key for each
namespace).
🪄 Autofix (Beta)
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: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 91d142bb-22d4-4780-8492-8b02fac40b8b
📒 Files selected for processing (5)
ci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-commands.shci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-ref.yamlci-operator/step-registry/etcd-encryption/vault-install/etcd-encryption-vault-install-commands.shci-operator/step-registry/etcd-encryption/vault-install/etcd-encryption-vault-install-ref.yamlci-operator/step-registry/etcd-encryption/vault-setup/etcd-encryption-vault-setup-chain.yaml
✅ Files skipped from review due to trivial changes (1)
- ci-operator/step-registry/etcd-encryption/vault-setup/etcd-encryption-vault-setup-chain.yaml
🚧 Files skipped from review as they are similar to previous changes (1)
- ci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-commands.sh
| Name of the transit encryption key for the secondary Vault instance. | ||
| Must differ from VAULT_KMS_KEY_NAME to ensure each instance uses a distinct KEK. |
There was a problem hiding this comment.
Clarify the rationale for distinct key names.
The documentation states the key names must differ "to ensure each instance uses a distinct KEK," but this reasoning is incorrect. Since configure_vault runs on separate Vault pods (vault-0 in vault-kms vs vault-0 in vault-kms-2), the key encryption keys are cryptographically distinct regardless of their names—they're stored in separate Vault instances with separate datastores.
Different key names aid clarity and organization, not key material distinctness.
📝 Suggested documentation fix
- name: VAULT_SECONDARY_KMS_KEY_NAME
default: "kms-key-2"
documentation: |-
Name of the transit encryption key for the secondary Vault instance.
- Must differ from VAULT_KMS_KEY_NAME to ensure each instance uses a distinct KEK.
+ Should differ from VAULT_KMS_KEY_NAME for clarity and to avoid confusion when managing multiple instances.📝 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.
| Name of the transit encryption key for the secondary Vault instance. | |
| Must differ from VAULT_KMS_KEY_NAME to ensure each instance uses a distinct KEK. | |
| Name of the transit encryption key for the secondary Vault instance. | |
| Should differ from VAULT_KMS_KEY_NAME for clarity and to avoid confusion when managing multiple instances. |
🤖 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
`@ci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-ref.yaml`
around lines 32 - 33, Update the explanatory sentence for the secondary transit
key so it no longer claims differing names produce distinct key material;
instead state that because configure_vault runs in separate Vault instances
(e.g., vault-0 in vault-kms vs vault-0 in vault-kms-2) their KEKs are stored
separately and cryptographically independent regardless of name, and that using
a different name from VAULT_KMS_KEY_NAME is recommended only for
clarity/organization and to avoid naming collisions; modify the text referencing
VAULT_KMS_KEY_NAME accordingly.
|
We have discussed this with @sandeepknd and we will move forward with this PR, if the CI is green |
openshift-ci
Bot
added
the
do-not-merge/hold
openshift-ci
Bot
changed the title
openshift-ci-robot
added
the
jira/valid-reference
|
@ardaguclu: This pull request explicitly references no jira issue. 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 openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci
Bot
removed
the
do-not-merge/work-in-progress
|
Thanks @ardaguclu . |
Thank you @sandeepknd |
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ardaguclu, sandeepknd The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
ardaguclu
force-pushed
the
multiple-vault
branch
from
e3fadfa to
4ac8efa
Compare
|
New changes are detected. LGTM label has been removed. |
|
[REHEARSALNOTIFIER]
Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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
`@ci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-commands.sh`:
- Line 103: Remove the sensitive AppRole credential output: delete or comment
out the echo that prints ROLE_ID (the line "echo \" - ROLE_ID: ${ROLE_ID}\"")
in the etcd-encryption-vault-configure-commands.sh summary block, or if you must
keep it for debugging, redact the value (e.g., replace ${ROLE_ID} with a fixed
"[REDACTED]" placeholder) so no secret is written to CI logs.
🪄 Autofix (Beta)
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: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: 4fa10162-80ba-4d9b-ac94-ef2b074c78c8
📒 Files selected for processing (5)
ci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-commands.shci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-ref.yamlci-operator/step-registry/etcd-encryption/vault-install/etcd-encryption-vault-install-commands.shci-operator/step-registry/etcd-encryption/vault-install/etcd-encryption-vault-install-ref.yamlci-operator/step-registry/etcd-encryption/vault-setup/etcd-encryption-vault-setup-chain.yaml
✅ Files skipped from review due to trivial changes (1)
- ci-operator/step-registry/etcd-encryption/vault-setup/etcd-encryption-vault-setup-chain.yaml
🚧 Files skipped from review as they are similar to previous changes (3)
- ci-operator/step-registry/etcd-encryption/vault-install/etcd-encryption-vault-install-ref.yaml
- ci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-ref.yaml
- ci-operator/step-registry/etcd-encryption/vault-install/etcd-encryption-vault-install-commands.sh
| echo " - Credentials Secret: vault-credentials (namespace: ${ns})" | ||
| echo " - Vault Enterprise Namespace: ${VAULT_ENTERPRISE_NS}" | ||
| echo " - Transit Key: ${key_name}" | ||
| echo " - ROLE_ID: ${ROLE_ID}" |
There was a problem hiding this comment.
Remove AppRole credential from logs.
Line 103 prints the ROLE_ID (AppRole role identifier) to CI logs. AppRole credentials are sensitive authentication material and should not be logged. As per coding guidelines, step-registry command scripts must never echo or print sensitive information such as passwords, tokens, or API keys.
A similar issue at the previous line 87 was addressed in an earlier commit, but this echo statement remains in the refactored summary block.
🔒 Proposed fix
Remove the ROLE_ID echo from the summary:
echo " - Vault Enterprise Namespace: ${VAULT_ENTERPRISE_NS}"
echo " - Transit Key: ${key_name}"
- echo " - ROLE_ID: ${ROLE_ID}"
echo ""Alternatively, if the line is kept for debugging purposes, redact the value:
- echo " - ROLE_ID: ${ROLE_ID}"
+ echo " - ROLE_ID: [REDACTED]"📝 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.
| echo " - ROLE_ID: ${ROLE_ID}" | |
| echo " - ROLE_ID: [REDACTED]" |
🤖 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
`@ci-operator/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-commands.sh`
at line 103, Remove the sensitive AppRole credential output: delete or comment
out the echo that prints ROLE_ID (the line "echo \" - ROLE_ID: ${ROLE_ID}\"")
in the etcd-encryption-vault-configure-commands.sh summary block, or if you must
keep it for debugging, redact the value (e.g., replace ${ROLE_ID} with a fixed
"[REDACTED]" placeholder) so no secret is written to CI logs.
Source: Coding guidelines
|
/pj-rehearse |
|
@ardaguclu: your |
|
/pj-rehearse |
|
@ardaguclu: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
@ardaguclu: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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. I understand the commands that are listed here. |
|
#80457 supersedes this |
openshift-ci
Bot
added
the
needs-rebase
|
PR needs rebase. DetailsInstructions 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. |
|
@ardaguclu: Closed this PR. 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. |
3 participants
Summary by CodeRabbit
This PR updates OpenShift CI's etcd-encryption ci-operator step-registry to install and configure two independent Vault Enterprise instances (primary and secondary) in separate namespaces so CI can expose two distinct KMS endpoints for etcd encryption testing.
What changed in practical terms
Key implementation highlights
Practical impact
Files of note