This document explains the security scanning tools used in this project, their configurations, and justifications for any filtered or skipped checks.

• Overview
• Security Tools
• Skipped Checks
• Running Security Scans
• Pre-commit Hooks
• CI/CD Integration

This project uses multiple security scanning tools to ensure:

• No hardcoded secrets or credentials
• Terraform configurations follow security best practices
• Shell scripts are safe from injection vulnerabilities
• IAM policies follow least-privilege principles

Current Status: 350 Checkov checks pass, 22 expected failures, 4 skipped (documented below).

These checks fail by design due to ROSA/OpenShift requirements:

The following patterns are allowlisted in .gitleaks.toml:

# Run all security checks
make security

# Run specific checks
make security-shell      # ShellCheck only
make security-terraform  # Checkov, tfsec, Grype
make security-secrets    # Gitleaks, pattern matching

# Run pre-commit hooks (includes security)
make pre-commit

# Checkov (full scan)
checkov -d . --framework terraform

# ShellCheck (all scripts)
find . -name "*.sh" -type f | xargs shellcheck -x -e SC1091

# Gitleaks
gitleaks detect --source . --config .gitleaks.toml

# tfsec
tfsec . --minimum-severity HIGH

# Grype
grype dir:. --only-fixed --fail-on high

Pre-commit hooks run automatically on git commit. Install with:

pip install pre-commit
pre-commit install

# Skip pre-commit (not recommended)
git commit --no-verify -m "message"

GitHub Actions runs security checks on all PRs and pushes to main.

Security findings are uploaded to GitHub Security tab via SARIF format:

• tfsec results
• Grype results
• Checkov results

When adding new security checks:

1. Test locally first:

   make security

2. If check fails with false positive:

   • Document the justification in this file
   • Add to skip list with comment explaining why
   • Update CI configuration if needed

3. Never skip checks without documentation.

For GovCloud deployments, this project enforces:

• Customer-managed KMS keys by default (cluster_kms_mode = "create", infra_kms_mode = "create")
• Private clusters only (no public API endpoints)
• FIPS-enabled OpenShift builds
• Encryption at rest for all data stores

All security scan results are:

• Logged in CI/CD (GitHub Actions)
• Uploaded to GitHub Security tab (SARIF)
• Available locally via make security

When OADP (backup/restore) is enabled, a Kubernetes Secret is created to configure AWS authentication. This project uses IRSA (IAM Roles for Service Accounts) rather than static AWS credentials.

┌─────────────────────────────────────────────────────────────────┐
│                    OADP Authentication Flow                      │
├─────────────────────────────────────────────────────────────────┤
│  1. Terraform creates IAM role with OIDC trust policy           │
│  2. Trust policy scopes role to OADP service accounts only      │
│  3. cloud-credentials Secret contains role ARN (not keys!)      │
│  4. Velero pods request token from OpenShift OIDC               │
│  5. AWS STS validates token, issues temporary credentials       │
│  6. Credentials expire in ~1 hour, auto-renewed                 │
└─────────────────────────────────────────────────────────────────┘

The cloud-credentials secret in openshift-adp namespace contains:

[default]
sts_regional_endpoints = regional
role_arn = arn:aws:iam::123456789:role/cluster-name-oadp-role
web_identity_token_file = /var/run/secrets/openshift/serviceaccount/token

This is NOT sensitive data - it only tells Velero which role to assume. The actual authentication happens via OIDC tokens that are:

• Generated per-pod
• Short-lived (~1 hour)
• Validated by AWS STS

The IAM role created by Terraform only trusts specific OIDC subjects:

{
  "Effect": "Allow",
  "Principal": {
    "Federated": "arn:aws:iam::ACCOUNT:oidc-provider/OIDC_ENDPOINT"
  },
  "Action": "sts:AssumeRoleWithWebIdentity",
  "Condition": {
    "StringEquals": {
      "OIDC_ENDPOINT:sub": [
        "system:serviceaccount:openshift-adp:openshift-adp-controller-manager",
        "system:serviceaccount:openshift-adp:velero"
      ]
    }
  }
}

Static AWS credentials would:

• Require manual rotation procedures
• Risk exposure if the secret is leaked
• Work from anywhere (not just the cluster)
• Not align with ROSA STS-mode best practices

IRSA ensures backup credentials can only be used by authorized OADP pods running on the cluster.

• Checkov Documentation
• ShellCheck Wiki
• Gitleaks Configuration
• tfsec Documentation
• Grype Documentation