Skip to content

InfoSec Keeper

Role in the Platform

InfoSec Keeper is the secrets-management system used by WxCIP automation and runtime services. It stores or brokers sensitive values such as AppRole credentials, service tokens, certificates, and automation credentials. Terraform manages selected policies, AppRoles, and backend configuration through TFE.

Do not confuse Keeper with KeepHQ

Keeper protects credentials. KeepHQ/EMS routes alert notifications.

Architecture

graph LR
    Dev["Reviewed Terraform Change"] --> Git["Terraform Repository"]
    Git --> TFE["Terraform Enterprise"]
    TFE --> Keeper["InfoSec Keeper"]
    Keeper --> Runtime["Exporters / Argo / Harness / AWX"]

Terraform defines the desired policies and authentication resources. Approved applications authenticate using their assigned method and retrieve only the paths permitted by least-privilege policy.

Terraform-Keeper Workflow

  1. Update the Keeper-related Terraform module or environment configuration.
  2. Open a pull request and review policy paths, capabilities, namespace, and consumers.
  3. Inspect the TFE speculative plan.
  4. Merge and approve the managed run according to the workspace policy.
  5. Validate the AppRole/policy/backend without displaying secret values.
  6. Confirm each downstream consumer can refresh and use the credential.
  7. Revoke the old credential only after the migration is verified.

Handling Rules

  • Never commit tokens, Secret IDs, private keys, generated certificates, or rendered secret files.
  • Do not paste secrets into chat, tickets, screenshots, pipeline logs, or shell history.
  • Store TFE variables as sensitive and limit workspace access.
  • Keep Role IDs and Secret IDs separate where the authentication design supports it.
  • Prefer short-lived credentials and documented rotation.
  • Give each service the minimum paths and capabilities it needs.
  • Treat a suspected disclosure as an incident and rotate immediately.

Base64 encoding is not encryption and is not an acceptable way to protect a Kubernetes Secret in Git.

Rotation Checklist

  1. Identify every consumer and current secret path.
  2. Create or rotate the credential using the approved workflow.
  3. Update consumers without exposing the value.
  4. Verify authentication and application health.
  5. Revoke the previous credential.
  6. Check audit logs for failed or unexpected use.
  7. Record evidence and the next rotation owner/date.

Troubleshooting

Symptom Check
Permission denied Namespace, policy path, capabilities, and identity role
Authentication fails Auth method, Role ID/Secret ID pairing, expiry, and clock skew
Works locally but not in pipeline Pipeline namespace/environment and secret connector
Rotation breaks exporter Consumer refresh behavior and old credential revocation timing
Terraform cannot update Keeper TFE workspace token, provider address, namespace, and policy
Secret appears in logs/state Stop the workflow, restrict access, rotate, and follow incident procedure

References