[security-audit-agent] Security Audit Findings — 2026-06-15

[rosa-regional-platform-ci]

Security Audit — rosa-regional-platform

Date: 2026-06-15
Auditor: Automated security-audit-agent
Method: Full static analysis of Terraform modules, ArgoCD/Helm charts, CI/CD scripts, Dockerfiles, shell scripts
Action required: Triage each finding below. This PR does not contain fixes — it exists to track and communicate security issues for owner review.

Supersedes: PR #566 (and earlier #511, #458), now closed. No user comments in any previous PR dismissed any finding as a non-issue, so all carry-over findings remain active.

---

CRITICAL Findings

CRIT-1 — API Gateway Resource Policy Allows Any AWS Principal (carry-over from #566, unresolved)

File: terraform/modules/api-gateway/resource-policy.tf lines 12–25

Principal = {
  AWS = "*"
}
Action = "execute-api:Invoke"

Risk: Principal: { AWS: "*" } permits any authenticated AWS principal in any account to invoke the platform APIs using valid SigV4 credentials. The comment in the file confirms this is intentional, but it means the AWS network perimeter provides no protection — the entire security model rests on the application layer alone.

Attack vector: An attacker with any AWS account (free tier) discovers the API Gateway invoke URL through DNS enumeration, generates valid SigV4 credentials, and makes authenticated API calls. If any application-layer authorization bug exists (see rosa-regional-platform-api audit), there is no AWS-level fallback.

Mitigation: Replace AWS = "*" with an aws:PrincipalOrgID or aws:PrincipalOrgPaths condition scoped to the Red Hat AWS Organization, or enumerate allowed AWS account ARNs explicitly.

---

CRIT-2 — Wildcard API Gateway ARN in IAM Policies for Prometheus and Loki Forwarders (carry-over from #566, unresolved)

Files:

• terraform/modules/prometheus-remote-write/iam.tf
• terraform/modules/loki-log-forwarder/iam.tf

Both roles allow: arn:aws:execute-api:<region>:<rc-account>:*/POST/...

Risk: The * wildcard in the API Gateway ID position means MC-side roles can invoke any API Gateway in the regional account with a matching path — including a rogue one created by an attacker.

Attack vector: Attacker with write access to the regional account creates a new API Gateway with the matching path. The MC-side Prometheus forwarder sends all metrics (including sensitive cluster telemetry) to the attacker-controlled endpoint.

Mitigation: Pass the RC API Gateway ID as a Terraform output via SSM Parameter Store or Terraform remote state and use it in the MC IAM policies to eliminate the wildcard.

---

CRIT-3 — Grafana Anonymous Authentication with Admin Role (carry-over from #566, unresolved)

File: argocd/config/regional-cluster/grafana/values.yaml

"auth.anonymous":
  enabled: true
  org_role: Admin

Risk: Any client that can reach the Grafana service — including any pod in the cluster — gets full admin access without credentials. An admin can delete/modify dashboards, reconfigure datasources to exfiltrate metrics, and create API keys for persistent access.

Attack vector: Compromised pod in the cluster issues curl http://grafana/api/dashboards and receives full admin access. If Grafana is ever accidentally exposed via Ingress, any internet user gets admin.

Mitigation: Configure SSO/OIDC authentication, or drop org_role to Viewer if anonymous read-only access is the intent. The disable_login_form setting does not protect the API.

---

CRIT-4 — Hardcoded Admin Password in Version Control (carry-over from #566, unresolved)

File: argocd/config/regional-cluster/grafana/values.yaml line 28

adminPassword: "admin"  # Static password prevents ArgoCD out-of-sync diffs.

Risk: The password admin is permanently in git history and trivially guessable. Any future regression that re-enables the login form exposes the admin account.

Mitigation: Replace with an ExternalSecret referencing AWS Secrets Manager. Use argocd.argoproj.io/compare-options: IgnoreExtraneous to prevent ArgoCD sync diffs.

---

HIGH Findings

HIGH-1 — CI Containerfile Installs AWS CLI Without GPG Signature Verification (NEW)

File: ci/Containerfile

RUN curl -fsSL "https://awscli.amazonaws.com/awscli-exe-linux-${AWS_ARCH}-${AWS_CLI_VERSION}.zip" -o "awscliv2.zip" && \
    unzip -qo awscliv2.zip && \
    ./aws/install

Risk: The AWS CLI is installed without GPG signature verification. The aws-nuke-cf/Containerfile in this same organization correctly verifies the GPG signature before installing. The CI container runs with AWS credentials in every CI pipeline job — a compromised binary exfiltrates those credentials.

Compare with aws-nuke-cf/Containerfile (correct pattern):

gpg --keyserver keyserver.ubuntu.com --recv-keys FB5DB77FD5C118B80511ADA8A6310ACC4672475C && \
gpg --verify awscliv2.zip.sig awscliv2.zip

Mitigation: Follow the same GPG verification pattern as aws-nuke-cf/Containerfile.

---

HIGH-2 — CI Containerfile Installs yq Without Checksum Verification (NEW)

File: ci/Containerfile

RUN curl -fsSL ".../yq_linux_${YQ_ARCH}" -o /usr/local/bin/yq && chmod +x /usr/local/bin/yq

Risk: yq is the only tool in this Containerfile installed without any integrity verification. Every other tool (Terraform, k6, Helm, promtool, AWS CLI) has checksum verification. This is an inconsistency that creates a supply chain gap.

Mitigation: Add SHA256 verification using the checksums published at the yq GitHub releases page.

---

HIGH-3 — CI Containerfile Base Image Uses Unpinned :latest Tag (carry-over, unresolved)

File: ci/Containerfile line 1

FROM registry.access.redhat.com/ubi9/ubi:latest

Risk: The CI image runs with AWS credentials. A silently updated UBI9 base with a regressed or compromised package could exfiltrate those credentials from every CI job.

Mitigation: Pin to a SHA256 digest.

---

HIGH-4 — IoT Policy Allows Wildcard Client IDs — Any Cert Holder Can Impersonate Any Management Cluster Agent (NEW)

File: terraform/modules/maestro-agent-iot-provisioning/main.tf lines ~53–57

{
  Action   = ["iot:Connect"]
  Resource = ["arn:aws:iot:...:client/*"]  # wildcard
}

Risk: The IoT Connect policy uses a client/* wildcard. AWS IoT Core uses client IDs for device identification. A stolen Maestro Agent certificate can connect with any client ID, including IDs belonging to other management clusters. This could allow cross-cluster MQTT message injection or impersonation.

Mitigation: Restrict to: arn:aws:iot:...:client/${var.management_cluster_id}-*

---

HIGH-5 — IoT Root CA Fetched from External URL at Terraform Plan Time (NEW)

File: terraform/modules/maestro-agent-iot-provisioning/main.tf

data "http" "aws_iot_root_ca" {
  url = "https://www.amazontrust.com/repository/AmazonRootCA1.pem"
}

Risk: The Amazon Root CA is fetched from an external URL at every terraform plan and terraform apply with no integrity verification. DNS poisoning or a compromised amazontrust.com delivery could inject a malicious CA into the IoT trust store.

Mitigation: Embed the Amazon Root CA 1 PEM directly as a Terraform local or variable. The certificate is static (versioned with fixed validity dates). Verify any update against the official published fingerprint before embedding.

---

HIGH-6 — ECS Bootstrap Task Role Has Permanent Cluster-Admin Access to EKS (NEW)

File: terraform/modules/ecs-bootstrap/iam.tf lines ~80–95

resource "aws_eks_access_policy_association" "bootstrap_cluster_admin" {
  policy_arn = "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
  access_scope { type = "cluster" }
}

Risk: The bootstrap task role is granted AmazonEKSClusterAdminPolicy with cluster-wide scope and retains this access indefinitely after bootstrap completes. Any actor who can assume this IAM role (e.g., by creating a new ECS task definition referencing it) gets full Kubernetes cluster-admin access at any time.

Mitigation: Revoke the EKS access entry for the bootstrap role after bootstrap completes. Implement this as a cleanup step in the bootstrap script itself, or as a time-bounded Terraform lifecycle.

---

MEDIUM Findings

MED-1 — uv Installer Script Runs Without Pre-Verification (NEW)

File: ci/Containerfile

RUN curl -fsSL "https://astral.sh/uv/${UV_VERSION}/install.sh" -o /tmp/uv-install.sh && \
    sh /tmp/uv-install.sh

Risk: The uv install script is downloaded and executed without verifying the script content or its signature. A compromised astral.sh domain or MITM attack silently compromises the CI build environment.

Mitigation: Download the uv binary directly from GitHub releases with SHA256 verification instead of using the install script.

---

MED-2 — Helm Install Script Piped to Bash Without Pre-Verification (carry-over, unresolved)

File: ci/Containerfile

RUN curl -fsSL ".../get-helm-3" | DESIRED_VERSION="${HELM_VERSION}" VERIFY_CHECKSUM=true bash

Risk: The install script itself is not verified before execution. Even with VERIFY_CHECKSUM=true (which verifies the Helm binary), a tampered script could bypass this verification.

Mitigation: Download the Helm binary directly from GitHub releases with GPG and checksum verification, following the same pattern used for Terraform in this Containerfile.

---

Full findings detail is in SECURITY-AUDIT.md added in this PR.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign psav for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[coderabbitai]

Warning

Review limit reached

@rosa-regional-platform-ci, we couldn't start this review because you've reached your PR review rate limit.

More reviews will be available in 59 minutes. 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 @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available.

Please see our Fair Usage Limits Policy for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: f135bfe1-96b1-47c5-b01e-1d2312384030

📥 Commits

Reviewing files that changed from the base of the PR and between 8decb36 and b547172.

📒 Files selected for processing (1)

• SECURITY-AUDIT.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[openshift-ci]

Hi @rosa-regional-platform-ci. Thanks for your PR.

I'm waiting for a openshift-online member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Tip

We noticed you've done this a few times! Consider joining the org to skip this step and gain /lgtm and other bot rights. We recommend asking approvers on your previous PRs to sponsor you.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

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.