Skip to content

NO-JIRA: Run 2 Vault instances in different namespaces #80405

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ardaguclu wants to merge 1 commit into from
Closed

NO-JIRA: Run 2 Vault instances in different namespaces #80405

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
161 changes: 87 additions & 74 deletions ...step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-commands.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,93 +3,106 @@ set -o nounset
set -o errexit
set -o pipefail

echo "========================================="
echo "Vault Configuration for KMS"
echo "========================================="
echo "Namespace: ${VAULT_NAMESPACE}"
echo "Vault Enterprise NS: ${VAULT_ENTERPRISE_NS}"
echo ""

export KUBECONFIG="${SHARED_DIR}/kubeconfig"

# In dev mode, Vault is already initialized and unsealed with root token "root"
ROOT_TOKEN="root"

echo "Configuring Vault for KMS..."
echo ""

# Create the Vault Enterprise namespace used by the KMS plugin
echo "Creating Vault Enterprise namespace '${VAULT_ENTERPRISE_NS}'..."
oc exec vault-0 -n "${VAULT_NAMESPACE}" -- \
env VAULT_TOKEN="${ROOT_TOKEN}" vault namespace create "${VAULT_ENTERPRISE_NS}"

# Enable transit secret engine
echo "Enabling transit secret engine..."
oc exec vault-0 -n "${VAULT_NAMESPACE}" -- \
env VAULT_TOKEN="${ROOT_TOKEN}" vault secrets enable -namespace="${VAULT_ENTERPRISE_NS}" -path=transit transit

# Create encryption key
echo "Creating transit encryption key..."
oc exec vault-0 -n "${VAULT_NAMESPACE}" -- \
env VAULT_TOKEN="${ROOT_TOKEN}" vault write -namespace="${VAULT_ENTERPRISE_NS}" -f transit/keys/${VAULT_KMS_KEY_NAME}

# Enable AppRole auth
echo "Enabling AppRole authentication..."
oc exec vault-0 -n "${VAULT_NAMESPACE}" -- \
env VAULT_TOKEN="${ROOT_TOKEN}" vault auth enable -namespace="${VAULT_ENTERPRISE_NS}" approle

# Create KMS policy
echo "Creating KMS policy..."
oc exec vault-0 -n "${VAULT_NAMESPACE}" -- \
sh -c "VAULT_TOKEN=${ROOT_TOKEN} vault policy write -namespace=${VAULT_ENTERPRISE_NS} kms-policy - <<POLICY
path \"transit/encrypt/${VAULT_KMS_KEY_NAME}\" {
# Configure a Vault instance for KMS encryption.
# Args: $1 = namespace, $2 = KMS key name, $3 = pod name
configure_vault() {
local ns="$1"
local key_name="$2"
local pod_name="$3"

echo ""
echo "========================================="
echo "Vault Configuration for KMS"
echo "========================================="
echo "Namespace: ${ns}"
echo "Vault Enterprise NS: ${VAULT_ENTERPRISE_NS}"
echo "KMS Key Name: ${key_name}"
echo ""

echo "Configuring Vault for KMS..."
echo ""

# Create the Vault Enterprise namespace used by the KMS plugin
echo "Creating Vault Enterprise namespace '${VAULT_ENTERPRISE_NS}'..."
oc exec "${pod_name}" -n "${ns}" -- \
env VAULT_TOKEN="${ROOT_TOKEN}" vault namespace create "${VAULT_ENTERPRISE_NS}"

# Enable transit secret engine
echo "Enabling transit secret engine..."
oc exec "${pod_name}" -n "${ns}" -- \
env VAULT_TOKEN="${ROOT_TOKEN}" vault secrets enable -namespace="${VAULT_ENTERPRISE_NS}" -path=transit transit

# Create encryption key
echo "Creating transit encryption key..."
oc exec "${pod_name}" -n "${ns}" -- \
env VAULT_TOKEN="${ROOT_TOKEN}" vault write -namespace="${VAULT_ENTERPRISE_NS}" -f "transit/keys/${key_name}"

# Enable AppRole auth
echo "Enabling AppRole authentication..."
oc exec "${pod_name}" -n "${ns}" -- \
env VAULT_TOKEN="${ROOT_TOKEN}" vault auth enable -namespace="${VAULT_ENTERPRISE_NS}" approle

# Create KMS policy
echo "Creating KMS policy..."
oc exec "${pod_name}" -n "${ns}" -- \
sh -c "VAULT_TOKEN=${ROOT_TOKEN} vault policy write -namespace=${VAULT_ENTERPRISE_NS} kms-policy - <<POLICY
path \"transit/encrypt/${key_name}\" {
capabilities = [\"update\"]
}
path \"transit/decrypt/${VAULT_KMS_KEY_NAME}\" {
path \"transit/decrypt/${key_name}\" {
capabilities = [\"update\"]
}
path \"transit/keys/${VAULT_KMS_KEY_NAME}\" {
path \"transit/keys/${key_name}\" {
capabilities = [\"read\"]
}
path \"sys/license/status\" {
capabilities = [\"read\"]
}
POLICY"

# Create AppRole role
echo "Creating AppRole role..."
oc exec vault-0 -n "${VAULT_NAMESPACE}" -- \
env VAULT_TOKEN="${ROOT_TOKEN}" vault write -namespace="${VAULT_ENTERPRISE_NS}" auth/approle/role/kms-plugin \
token_policies=kms-policy \
token_ttl=1h \
token_max_ttl=4h

# Get AppRole credentials
echo "Retrieving AppRole credentials..."
ROLE_ID=$(oc exec vault-0 -n "${VAULT_NAMESPACE}" -- \
env VAULT_TOKEN="${ROOT_TOKEN}" vault read -namespace="${VAULT_ENTERPRISE_NS}" -field=role_id auth/approle/role/kms-plugin/role-id)
SECRET_ID=$(oc exec vault-0 -n "${VAULT_NAMESPACE}" -- \
env VAULT_TOKEN="${ROOT_TOKEN}" vault write -namespace="${VAULT_ENTERPRISE_NS}" -field=secret_id -f auth/approle/role/kms-plugin/secret-id)

# Create vault-credentials secret
echo "Creating vault-credentials secret..."
oc create secret generic vault-credentials \
--from-literal=role-id="${ROLE_ID}" \
--from-literal=secret-id="${SECRET_ID}" \
--from-literal=root-token="${ROOT_TOKEN}" \
-n "${VAULT_NAMESPACE}"

echo "Vault credentials saved to vault-credentials secret"

echo ""
echo "========================================="
echo "Vault Configuration Complete"
echo "========================================="
echo ""
echo "Summary:"
echo " - Vault Service: vault.${VAULT_NAMESPACE}.svc:8200"
echo " - Credentials Secret: vault-credentials (namespace: ${VAULT_NAMESPACE})"
echo " - Vault Enterprise Namespace: ${VAULT_ENTERPRISE_NS}"
echo " - Transit Key: ${VAULT_KMS_KEY_NAME}"
echo " - ROLE_ID: ${ROLE_ID}"
echo ""
# Create AppRole role
echo "Creating AppRole role..."
oc exec "${pod_name}" -n "${ns}" -- \
env VAULT_TOKEN="${ROOT_TOKEN}" vault write -namespace="${VAULT_ENTERPRISE_NS}" auth/approle/role/kms-plugin \
token_policies=kms-policy \
token_ttl=1h \
token_max_ttl=4h

# Get AppRole credentials
echo "Retrieving AppRole credentials..."
ROLE_ID=$(oc exec "${pod_name}" -n "${ns}" -- \
env VAULT_TOKEN="${ROOT_TOKEN}" vault read -namespace="${VAULT_ENTERPRISE_NS}" -field=role_id auth/approle/role/kms-plugin/role-id)
SECRET_ID=$(oc exec "${pod_name}" -n "${ns}" -- \
env VAULT_TOKEN="${ROOT_TOKEN}" vault write -namespace="${VAULT_ENTERPRISE_NS}" -field=secret_id -f auth/approle/role/kms-plugin/secret-id)

# Create vault-credentials secret
echo "Creating vault-credentials secret..."
oc create secret generic vault-credentials \
--from-literal=role-id="${ROLE_ID}" \
--from-literal=secret-id="${SECRET_ID}" \
--from-literal=root-token="${ROOT_TOKEN}" \
-n "${ns}"

echo "Vault credentials saved to vault-credentials secret"

echo ""
echo "========================================="
echo "Vault Configuration Complete"
echo "========================================="
echo ""
echo "Summary:"
echo " - Vault Service: vault.${ns}.svc:8200"
echo " - Credentials Secret: vault-credentials (namespace: ${ns})"
echo " - Vault Enterprise Namespace: ${VAULT_ENTERPRISE_NS}"
echo " - Transit Key: ${key_name}"
echo " - ROLE_ID: ${ROLE_ID}"

@coderabbitai coderabbitai Bot Jun 11, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

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.

Suggested change
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

echo ""
}

configure_vault "${VAULT_NAMESPACE}" "${VAULT_KMS_KEY_NAME}" "vault-0"
configure_vault "${VAULT_SECONDARY_NAMESPACE}" "${VAULT_SECONDARY_KMS_KEY_NAME}" "vault-2-0"
9 changes: 9 additions & 0 deletions ...or/step-registry/etcd-encryption/vault-configure/etcd-encryption-vault-configure-ref.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,6 +22,15 @@ ref:
Vault Enterprise namespace where the transit engine, AppRole auth, and
policies will be created. Must match the VaultNamespace configured in the
KMS plugin (defaults to "admin" in library-go test helpers).
- name: VAULT_SECONDARY_NAMESPACE
default: "vault-kms-2"
documentation: |-
Namespace for a second Vault Enterprise instance to configure.
- 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.
Comment on lines +32 to +33

@coderabbitai coderabbitai Bot Jun 11, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

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.

Suggested change
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.

documentation: |-
Configures an already-installed Vault instance for Kubernetes KMS encryption.

Expand Down
Loading