SEC-006 recommended Secret Security

Least Privilege Access to Secrets

Secret access follows least privilege - dedicated service accounts, limited human access, audit trails

Question to ask

"How many people on your team can read production database passwords?"

What to check

  • Secret manager IAM/access policies
  • Role-based access patterns in Terraform/IaC
  • Dedicated service accounts for applications
  • No overly broad access patterns (allUsers, admin roles)

Pass criteria

  • Production secrets accessible only to prod workloads + limited humans
  • Applications use dedicated service accounts
  • Developers cannot read prod secrets without approval
  • Access changes are logged/auditable

Verification guide

Severity: Recommended

Access to secrets should follow the principle of least privilege. Applications use dedicated service accounts with scoped access. Humans have limited access to production secrets with audit trails.

Check automatically:

  1. Check secret manager IAM/access policies:
# GCP - check IAM bindings for Secret Manager
gcloud secrets list --format="value(name)" 2>/dev/null | head -5
# Then for each: gcloud secrets get-iam-policy SECRET_NAME

# AWS - check Secrets Manager resource policies
aws secretsmanager list-secrets --query 'SecretList[].Name' 2>/dev/null | head -5

# Terraform IAM configurations
grep -rE "secretmanager|secrets_manager" terraform/ --include="*.tf" 2>/dev/null | head -10
  1. Check for role-based access patterns:
# Terraform/IaC defining secret access
grep -rE "secretAccessor|SecretsManagerReadWrite|secret.*policy" terraform/ cloudformation/ 2>/dev/null

# Service accounts with secret access
grep -rE "serviceAccount.*secret|role.*secret" terraform/ k8s/ 2>/dev/null
  1. Check application service accounts (should have minimal permissions):
# Kubernetes service account annotations
grep -rE "serviceAccountName:|iam.gke.io/gcp-service-account" k8s/ kubernetes/ 2>/dev/null

# Check if app uses dedicated service account (not default)
grep -rE "serviceAccount:" k8s/ kubernetes/ 2>/dev/null
  1. Check for overly broad access patterns (anti-patterns):
# Everyone can access all secrets (bad)
grep -rE "allUsers|allAuthenticatedUsers|\*.*secret" terraform/ 2>/dev/null

# Admin/owner roles for secret access (should be reader/accessor)
grep -rE "roles/owner|roles/editor|AdministratorAccess" terraform/ 2>/dev/null | grep -i secret

Ask user:

  • "Who can access production secrets?" (should be minimal)
  • "Do applications have dedicated service accounts with scoped access?"
  • "Can developers read production secrets directly?"
  • "Is there an approval process for production secret access?"

Cross-reference with:

  • SEC-001 (secret manager - where access is controlled)
  • ACCESS-001 (production access - related concept)
  • ACCESS-002 (tiered access)
  • ADMIN-002 (admin panel security - audit trails)

Pass criteria:

  • Production secrets accessible only to production workloads + limited humans
  • Applications use dedicated service accounts (not personal credentials)
  • Developers cannot read production secrets without approval/audit
  • Secret access follows principle of least privilege
  • Access changes are logged/auditable

Fail criteria:

  • Everyone on the team can read all secrets
  • Applications use broad "admin" credentials
  • No distinction between dev and prod secret access
  • No audit trail for secret access grants

Evidence to capture:

  • Who/what can access production secrets
  • Service account strategy for applications
  • Approval process for human access to prod secrets
  • Where access grants are audited

Section

29. Secrets Management

Code Quality & Architecture