Repository navigation
OSAC-1568: Add local Vault infrastructure and e2e workflow - #72
Conversation
|
@eliorerz: This pull request references OSAC-1568 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the task to target the "5.0.0" version, but no target version was set. 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. |
|
Warning Review limit reached
More reviews will be available in 41 minutes and 28 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Repository: osac-project/coderabbit/.coderabbit.yaml Review profile: ASSERTIVE Plan: Enterprise Run ID: 📒 Files selected for processing (12)
WalkthroughAdds a complete HashiCorp Vault deployment for OSAC CI runners: Vault HCL configuration and Podman Quadlet container unit for containerized server, host prerequisite installer script, 10-phase orchestration setup script covering initialization through policy/role creation, unseal script with systemd fallback service, backup script with daily timer, and health-check validation script. Also adds GitHub Actions E2E test dispatcher workflow and reusable workflow that authenticate to Vault via GitHub OIDC JWT and retrieve secrets for test execution. ChangesVault Deployment Infrastructure
E2E Test CI Workflow Integration
Sequence Diagram(s)sequenceDiagram
participant op as Operator
participant setup as vault-setup.sh
participant sd as systemd --user
participant api as Vault API<br/>(127.0.0.1:8200)
participant gh as GitHub OIDC
op->>setup: bash vault-setup.sh
setup->>setup: Phase 1-2: mkdir ~/.vault-server, copy config + scripts
setup->>sd: Phase 3: install Quadlet + units, daemon-reload, start vault.service
sd-->>api: vault.service launching Podman container
setup->>api: poll vault status until reachable
setup->>api: Phase 4: vault operator init (shares=3, threshold=2)
api-->>setup: init JSON (root_token + unseal_keys_b64)
setup->>setup: Phase 5: extract .unseal-keys (chmod 0600)
setup->>api: Phase 6: vault-unseal.sh (apply keys)
setup->>api: Phase 7: enable KV v2 at secret/
setup->>gh: Phase 8: JWT auth mount + GitHub OIDC discovery URL
setup->>api: Phase 9: osac-e2e policy + JWT role (bound claims)
setup->>sd: Phase 10: loginctl linger + backup timer enable/start
setup-->>op: completion banner + next steps
sequenceDiagram
participant gh as GitHub (OIDC)
participant workflow as e2e-vault-secrets.yml
participant vault as Vault API
participant runner as osac-ci runner
participant container as Test container<br/>(podman)
gh->>workflow: trigger (pull_request or workflow_dispatch)
workflow->>gh: request OIDC JWT token
gh-->>workflow: GitHub OIDC JWT
workflow->>vault: authenticate via hashicorp/vault-action@v4 + JWT
vault-->>workflow: Vault token (JWT role osac-e2e)
workflow->>vault: retrieve pull-secret and aap-license
vault-->>workflow: secret values
workflow->>runner: write secrets to /tmp/*.txt (chmod 600)
runner->>container: podman run with --volume mounts for secrets
container->>container: pytest with env vars, kubeconfig, secret files
container-->>runner: test results (JUnit XML, verbose logs)
runner->>runner: always(): remove /tmp secret files
workflow-->>gh: result output (PASSED or FAILED)
Estimated code review effort🎯 4 (Complex) | ⏱️ ~75 minutes Suggested reviewers
Poem
Caution Pre-merge checks failedPlease resolve all errors before merging. Addressing warnings is optional.
❌ Failed checks (1 error, 2 warnings)
✅ Passed checks (8 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 |
There was a problem hiding this comment.
Actionable comments posted: 9
🤖 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 `@vault/scripts/vault-backup.sh`:
- Around line 27-29: The pruned backup count in the find command is inaccurate
because the current order of `-print -delete` causes files to be printed before
deletion is attempted, meaning files that fail to delete are still counted. Fix
this by reordering the find predicates so that `-delete` comes before `-print`,
which ensures only successfully deleted files are counted in the pruned variable
and logged in the subsequent echo statement.
In `@vault/scripts/vault-health-check.sh`:
- Around line 45-51: The authenticated vault commands in checks 6 and 7 (vault
read auth/jwt/role/osac-e2e and vault policy read osac-e2e) will fail without a
VAULT_TOKEN set in the script. Source the root token from the vault
initialization file ~/.vault-server/.vault-init.json at the beginning of the
script (similar to how vault-setup.sh does it) to extract and set VAULT_TOKEN as
an environment variable. This will allow the script to run independently without
requiring the caller to pre-export the token.
In `@vault/scripts/vault-prerequisites.sh`:
- Around line 1-4: The vault-prerequisites.sh script documents that it should be
run as root but lacks a programmatic guard to enforce this requirement. Add an
EUID check immediately after the "set -euo pipefail" line to verify that the
effective user ID is 0 (root). If the check fails, the script should print a
clear error message and exit with a non-zero status code. This prevents delayed,
confusing failures during package installation attempts and provides immediate
feedback to users running the script without sufficient privileges.
- Around line 21-33: The script unconditionally installs yum-utils in the
initial package installation step, but yum-config-manager used later in the
HashiCorp repository configuration requires different packages depending on the
package manager: yum-utils for YUM-based systems and dnf-plugins-core for
DNF-based systems. Modify the package installation logic at the beginning of the
script to conditionally install the appropriate package manager utilities based
on the value of PKG_MGR variable, ensuring that the correct plugin package is
installed to support yum-config-manager (or its DNF equivalent) before the
HashiCorp repository configuration attempt.
In `@vault/scripts/vault-setup.sh`:
- Around line 137-149: The VAULT_TOKEN is sourced from the .vault-init.json file
in the conditional block (checking the VAULT_HOME path), but this file is
deleted later in the script around line 215. This causes subsequent reruns of
the script to fail authentication during phases 7-9 operations since there is no
automatic token source available. Either move the deletion of the
.vault-init.json file to the very end of the script after all Vault operations
complete, or add a validation check before phases 7-9 that ensures VAULT_TOKEN
is set and provides clear error messaging if it is not available, guiding the
user to provide authentication credentials.
- Around line 182-190: The JWT role for osac-e2e in the vault write
auth/jwt/role/osac-e2e command currently only restricts access based on
repository_owner, allowing any repository in the org to request tokens with the
osac-e2e policy. Enhance the bound_claims object to include additional
restrictive claims such as explicit repository name, ref, and workflow
constraints to limit token issuance to only the specific repositories and
workflows that actually need the osac-e2e policy, following the principle of
least privilege.
- Around line 87-92: The for loop that retries checking the Vault status field
'type' has no failure handling—if all 30 iterations complete without the
condition being met, the script silently continues to the next part. After the
for loop ends (after the done statement), add an explicit check that verifies
the vault_status_field 'type' is still valid, and if it is empty or null, echo
an error message and exit with a non-zero status code to immediately surface the
root cause of Vault being unreachable rather than allowing the setup to continue
with a failed Vault connection.
In `@vault/scripts/vault-unseal.sh`:
- Line 63: The hardcoded threshold value of 2 in vault-unseal.sh duplicates the
vault configuration defined in vault-setup.sh phase 4, which creates a
maintenance risk if these values diverge. Extract the threshold value into a
shared configuration file that both vault-unseal.sh and vault-setup.sh can
source, or if that's not feasible, add a clear comment above the threshold
assignment that explicitly references the corresponding threshold definition in
vault-setup.sh phase 4 to document the dependency and keep them synchronized.
- Around line 56-59: The script exits with code 0 when the UNSEAL_KEYS_FILE is
not found, which signals success even though Vault remains sealed and unsealing
failed. This masks critical failures when the keys file is accidentally deleted
or missing. Change the exit code from 0 to 1 in the conditional block that
checks for the missing unseal keys file (the if statement checking [[ ! -f
"${UNSEAL_KEYS_FILE}" ]]), so the script properly signals failure when required
keys are missing and cannot proceed with unsealing.
🪄 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: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 9c1ca0b3-1f16-4596-8183-7c30d17d670b
📒 Files selected for processing (10)
vault/config/vault.hclvault/quadlet/vault.containervault/scripts/vault-backup.shvault/scripts/vault-health-check.shvault/scripts/vault-prerequisites.shvault/scripts/vault-setup.shvault/scripts/vault-unseal.shvault/vault-backup.servicevault/vault-backup.timervault/vault-unseal.service
| vault write auth/jwt/role/osac-e2e - <<'ROLE' | ||
| { | ||
| "role_type": "jwt", | ||
| "bound_claims": {"repository_owner": "osac-project"}, | ||
| "user_claim": "repository", | ||
| "token_policies": ["osac-e2e"], | ||
| "token_ttl": "60m", | ||
| "token_max_ttl": "120m" | ||
| } |
There was a problem hiding this comment.
Tighten JWT role claims to least privilege.
The role is only bound to repository_owner, so any repository in that org can request a Vault token with osac-e2e policy. Restrict to explicit repository/ref/workflow claims.
Proposed fix
{
"role_type": "jwt",
- "bound_claims": {"repository_owner": "osac-project"},
+ "bound_claims_type": "glob",
+ "bound_claims": {
+ "repository": "osac-project/osac-repo-name",
+ "ref": "refs/heads/main"
+ },
"user_claim": "repository",
"token_policies": ["osac-e2e"],
"token_ttl": "60m",
"token_max_ttl": "120m"
}🤖 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 `@vault/scripts/vault-setup.sh` around lines 182 - 190, The JWT role for
osac-e2e in the vault write auth/jwt/role/osac-e2e command currently only
restricts access based on repository_owner, allowing any repository in the org
to request tokens with the osac-e2e policy. Enhance the bound_claims object to
include additional restrictive claims such as explicit repository name, ref, and
workflow constraints to limit token issuance to only the specific repositories
and workflows that actually need the osac-e2e policy, following the principle of
least privilege.
6d663ea to
ade5688
Compare
ade5688 to
6a091bf
Compare
There was a problem hiding this comment.
Actionable comments posted: 5
♻️ Duplicate comments (1)
vault/scripts/vault-setup.sh (1)
194-207: 🧹 Nitpick | 🔵 Trivial | 💤 Low valueConsider tightening JWT role claims to explicit repository and ref patterns.
The role binds to
repository_ownerandenvironment, which restricts access to workflows in the osac-project org running in the e2e-test environment. However, this still allows any repository in the org to obtain tokens. For least-privilege security, consider adding explicitrepositoryandrefclaim restrictions.🔒 Example with tighter claim restrictions
"bound_claims": { "repository_owner": "osac-project", + "repository": "osac-project/osac-test-infra", + "ref": "refs/heads/main" },Or use glob patterns if multiple repos/refs need access:
+ "bound_claims_type": "glob", "bound_claims": { - "repository_owner": "osac-project", - "environment": "e2e-test" + "repository": "osac-project/*", + "ref": "refs/heads/main" },🤖 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 `@vault/scripts/vault-setup.sh` around lines 194 - 207, The JWT role configuration for osac-e2e in the vault write command currently has too permissive bound_claims that only restrict by repository_owner and environment, allowing any repository in the org to obtain tokens. Add explicit repository and ref claim restrictions to the bound_claims object within the osac-e2e role configuration to enforce least-privilege access, either by specifying exact repository names and git refs or by using glob patterns if multiple repos or refs need access.
🤖 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 @.github/workflows/e2e-vault-secrets.yml:
- Around line 69-94: The "Run E2E tests" step directly expands workflow inputs
(inputs.test-suite, inputs.test-filter, inputs.namespace, inputs.vm-template)
within the shell script context, which creates a command injection
vulnerability. Move these workflow inputs to an env block at the step level,
then reference them as shell environment variables (like $TEST_SUITE_INPUT,
$TEST_FILTER_INPUT, $NAMESPACE_INPUT, $VM_TEMPLATE_INPUT) instead of using the
GitHub Actions template syntax directly in the run script. This ensures proper
variable handling and prevents shell metacharacter injection.
- Around line 61-67: The shell commands directly interpolate Vault secrets using
template expansion syntax which is vulnerable to shell injection if secrets
contain special characters like single quotes. To fix this, pass the secrets as
environment variables to the step instead of directly expanding them inline,
then reference those environment variables in the shell commands. This prevents
the shell from interpreting any special characters within the secret values.
Apply this approach to both the PULL_SECRET and AAP_LICENSE secret outputs in
the "Write secrets to files" step.
- Line 50: In the `.github/workflows/e2e-vault-secrets.yml` file, replace the
`hashicorp/vault-action@v4` reference with the pinned commit SHA
`hashicorp/vault-action@892a26828f195e65540a40b4768ae4571f51ebfc` to ensure the
workflow uses an immutable commit SHA instead of a mutable tag, which prevents
potential supply-chain attacks from tag modifications.
In `@vault/quadlet/vault.container`:
- Around line 33-34: The AutoUpdate=registry directive in the vault.container
file causes automatic updates to new minor/patch versions within the 2.0.x line,
introducing instability for CI runners. Replace the floating version reference
in the Image specification with an exact Vault version tag (for example, using
2.0.2 instead of 2.0) and either remove the AutoUpdate=registry line or change
it to a more restrictive auto-update policy that maintains CI stability by
requiring deliberate version updates after testing.
In `@vault/scripts/vault-prerequisites.sh`:
- Around line 43-47: The code at lines 43-47 is redundantly checking for package
managers using command -v checks for dnf-3 and dnf, but the package manager was
already detected and stored in the PKG_MGR variable at lines 14-21. Remove the
conditional logic that checks for dnf-3 and dnf commands, and instead directly
use the PKG_MGR variable to decide whether to use dnf config-manager or
yum-config-manager for adding the repository. This leverages the existing
package manager detection and eliminates the check for the non-standard dnf-3
command.
---
Duplicate comments:
In `@vault/scripts/vault-setup.sh`:
- Around line 194-207: The JWT role configuration for osac-e2e in the vault
write command currently has too permissive bound_claims that only restrict by
repository_owner and environment, allowing any repository in the org to obtain
tokens. Add explicit repository and ref claim restrictions to the bound_claims
object within the osac-e2e role configuration to enforce least-privilege access,
either by specifying exact repository names and git refs or by using glob
patterns if multiple repos or refs need access.
🪄 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: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: c2cf55d5-4fb5-4311-87b5-d7f2489189f4
📒 Files selected for processing (12)
.github/workflows/e2e-test.yml.github/workflows/e2e-vault-secrets.ymlvault/config/vault.hclvault/quadlet/vault.containervault/scripts/vault-backup.shvault/scripts/vault-health-check.shvault/scripts/vault-prerequisites.shvault/scripts/vault-setup.shvault/scripts/vault-unseal.shvault/vault-backup.servicevault/vault-backup.timervault/vault-unseal.service
6a091bf to
74086e1
Compare
|
/lgtm |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: eliorerz, omer-vishlitzky 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 |
There was a problem hiding this comment.
Actionable comments posted: 2
♻️ Duplicate comments (2)
.github/workflows/e2e-vault-secrets.yml (1)
81-103:⚠️ Potential issue | 🟠 Major | ⚡ Quick winQuote pytest args via an array; current expansion is unsafe and can misparse filters.
On Line 102,
pytest ${TEST_ARGS} ${FILTER_ARGS}performs word splitting on input-derived values. This breaks valid filters likefoo and barand allows unintended extra pytest flags to be injected viatest-filter. Buildpytestargs as an array and expand with"${PYTEST_ARGS[@]}".Suggested fix
- name: Run E2E tests id: test env: TEST_SUITE: ${{ inputs.test-suite }} TEST_FILTER: ${{ inputs.test-filter }} OSAC_NAMESPACE: ${{ inputs.namespace }} OSAC_VM_TEMPLATE: ${{ inputs.vm-template }} TEST_IMAGE: ${{ inputs.test-image }} run: | - TEST_ARGS="tests/" + TEST_PATH="tests/" if [ -n "${TEST_SUITE}" ]; then - TEST_ARGS="tests/${TEST_SUITE}/" + TEST_PATH="tests/${TEST_SUITE}/" fi - FILTER_ARGS="" + PYTEST_ARGS=("${TEST_PATH}") if [ -n "${TEST_FILTER}" ]; then - FILTER_ARGS="-k ${TEST_FILTER}" + PYTEST_ARGS+=("-k" "${TEST_FILTER}") fi podman run --rm \ --network host \ -v "${HOME}/.kube/config:/root/.kube/config:ro,Z" \ -v "${RUNNER_TEMP}/pull-secret.json:/root/pull-secret:ro,Z" \ -v "${RUNNER_TEMP}/aap-license.zip:/root/aap-license.zip:ro,Z" \ -e KUBECONFIG=/root/.kube/config \ -e OSAC_VM_KUBECONFIG=/root/.kube/config \ -e OSAC_NAMESPACE="${OSAC_NAMESPACE}" \ -e OSAC_VM_TEMPLATE="${OSAC_VM_TEMPLATE}" \ -e OSAC_PULL_SECRET_PATH=/root/pull-secret \ "${TEST_IMAGE}" \ - pytest ${TEST_ARGS} ${FILTER_ARGS} \ + pytest "${PYTEST_ARGS[@]}" \ --junitxml=/tmp/junit.xml -vAs per coding guidelines, "Flag injection vectors: SQL string concatenation, shell=True with user input, eval/exec on untrusted data, ... os.system with variables, and dangerouslySetInnerHTML with user data", this input-derived shell argument expansion should not be unquoted.
🤖 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 @.github/workflows/e2e-vault-secrets.yml around lines 81 - 103, The pytest command on line 102 uses unquoted variable expansion with TEST_ARGS and FILTER_ARGS which is unsafe and can cause word splitting and command injection. Convert the pytest arguments to a bash array named PYTEST_ARGS, initialize it with the TEST_ARGS value, conditionally add FILTER_ARGS to the array if TEST_FILTER is set, and then invoke pytest with proper array expansion using "${PYTEST_ARGS[@]}" instead of the current unquoted ${TEST_ARGS} ${FILTER_ARGS} pattern to ensure safe argument handling.Sources: Coding guidelines, Linters/SAST tools
vault/scripts/vault-setup.sh (1)
194-206:⚠️ Potential issue | 🟠 Major | ⚡ Quick winJWT role binding is still broader than needed for least privilege.
Lines 197-200 allow any repo under
osac-projectwith matching environment claim to request this policy. Narrow claims to the exact repository (and optionally workflow) that should readosac-e2esecrets.🔒 Proposed tightening
{ "role_type": "jwt", "bound_claims": { - "repository_owner": "osac-project", + "repository": "osac-project/osac-test-infra", "environment": "e2e-test" }, "bound_audiences": ["https://github.com/osac-project"], "user_claim": "repository", "token_policies": ["osac-e2e"], "token_ttl": "60m", "token_max_ttl": "120m" }🤖 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 `@vault/scripts/vault-setup.sh` around lines 194 - 206, The bound_claims in the JWT role binding for osac-e2e is too permissive and violates the principle of least privilege. Currently, it only checks repository_owner and environment, allowing any repository under osac-project with the matching environment claim to request access. Add a more specific constraint to the bound_claims by including the exact repository name (and optionally the workflow name) that should be permitted to authenticate with this role, so that only the intended repository can request the osac-e2e policy.
🤖 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 `@vault/scripts/vault-setup.sh`:
- Around line 49-53: The chown command that sets ownership on the VAULT_HOME
data and logs directories requires root privileges but the script runs in
user-session mode with set -e enabled, causing it to terminate the script if
executed by a non-root user. Make the ownership adjustment rootless-safe by
either appending || true to the chown line to allow it to fail gracefully
without aborting the script, or by conditionally executing it only when the user
has root privileges using a check like if [[ "$EUID" -eq 0 ]]; then before the
chown command.
In `@vault/vault-backup.timer`:
- Around line 7-9: The OnCalendar schedule in the [Timer] section is using the
host's local timezone instead of explicitly specifying UTC, which causes the
backup job to run at different local times depending on the runner's timezone
configuration. Add Timezone=UTC as a new line in the [Timer] section near the
existing OnCalendar and RandomizedDelaySec directives to ensure the 03:00:00
schedule runs consistently at UTC across all environments.
---
Duplicate comments:
In @.github/workflows/e2e-vault-secrets.yml:
- Around line 81-103: The pytest command on line 102 uses unquoted variable
expansion with TEST_ARGS and FILTER_ARGS which is unsafe and can cause word
splitting and command injection. Convert the pytest arguments to a bash array
named PYTEST_ARGS, initialize it with the TEST_ARGS value, conditionally add
FILTER_ARGS to the array if TEST_FILTER is set, and then invoke pytest with
proper array expansion using "${PYTEST_ARGS[@]}" instead of the current unquoted
${TEST_ARGS} ${FILTER_ARGS} pattern to ensure safe argument handling.
In `@vault/scripts/vault-setup.sh`:
- Around line 194-206: The bound_claims in the JWT role binding for osac-e2e is
too permissive and violates the principle of least privilege. Currently, it only
checks repository_owner and environment, allowing any repository under
osac-project with the matching environment claim to request access. Add a more
specific constraint to the bound_claims by including the exact repository name
(and optionally the workflow name) that should be permitted to authenticate with
this role, so that only the intended repository can request the osac-e2e policy.
🪄 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: osac-project/coderabbit/.coderabbit.yaml
Review profile: ASSERTIVE
Plan: Enterprise
Run ID: 41402ffd-8d91-47fc-85e6-dc50f947f66f
📒 Files selected for processing (12)
.github/workflows/e2e-test.yml.github/workflows/e2e-vault-secrets.ymlvault/config/vault.hclvault/quadlet/vault.containervault/scripts/vault-backup.shvault/scripts/vault-health-check.shvault/scripts/vault-prerequisites.shvault/scripts/vault-setup.shvault/scripts/vault-unseal.shvault/vault-backup.servicevault/vault-backup.timervault/vault-unseal.service
Deploy a team-owned HashiCorp Vault instance for CI e2e test secrets: - Vault server config (file storage, localhost-only, no TLS) - Podman Quadlet unit file for systemd-managed container - Setup, unseal, backup, health-check, and prerequisites scripts - Systemd services for auto-unseal and daily backups - JWT auth configured for GitHub OIDC with bound claims (repository_owner + environment) and bound audiences Add reusable GitHub Actions e2e workflow: - vault-action@v4 retrieves secrets via OIDC JWT auth - Caller workflow triggers on pull_request and workflow_dispatch - Runs on self-hosted osac-ci runners with e2e-test environment
74086e1 to
e577b14
Compare
|
New changes are detected. LGTM label has been removed. |
|
/override ci/prow/e2e-vmaas |
|
@eliorerz: Overrode contexts on behalf of eliorerz: ci/prow/e2e-vmaas 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. |
Summary
repository_owner: osac-project,environment: e2e-test) and bound audienceshashicorp/vault-action@v4for secret retrieval via OIDC JWTpull_requestandworkflow_dispatchFiles
vault/config/vault.hcl0.0.0.0:8200in container, TLS disabled,disable_mlock)vault/quadlet/vault.containervault:2.0, localhost-only publish, SELinux:Zvolumes, auto-unseal viaExecStartPost)vault/scripts/vault-prerequisites.shvault/scripts/vault-setup.shvault/scripts/vault-unseal.shvault/scripts/vault-backup.shvault/scripts/vault-health-check.shvault/vault-unseal.servicevault/vault-backup.servicevault/vault-backup.timer.github/workflows/e2e-vault-secrets.yml.github/workflows/e2e-test.ymlpull_requestandworkflow_dispatchDeployment
Test plan
secret/osac/e2e/testsystemctl --user start vault-backup.servicecreates timestamped tarballid-token: writeSummary by CodeRabbit
Release Notes