Security Best Practices

This guide provides task-focused security recommendations for deploying and operating Control Core.

For secure diagnostics and support data-sharing guardrails, see:

• Observability & Trust
• Security of Support
• PBAC Operator Playbooks

Overview

Control Core supports enterprise-grade security through policy-based access control, audit logging, and optional workload identity. Follow these practices to secure your deployment.

Security Layers

Security is applied at multiple layers from network to application:

Access Management

• Use API keys securely: Store Bouncer API keys in secrets management; never commit them to source control.
• Rotate keys regularly: Rotate Control Plane and Bouncer API keys on a schedule.
• Least privilege: Grant users and services only the permissions they need.
• Enable MFA: Use multi-factor authentication for administrative access where supported.

Network Security

• TLS for all traffic: Use HTTPS for Control Plane and Bouncer; terminate TLS at load balancer or proxy.
• Restrict network access: Place Control Plane and Bouncers in private subnets; expose only necessary ports.
• Firewall rules: Allow only required ports (e.g., 443, 8080 for Bouncer, 8000 for Control Plane API).

Cryptographic Workload Identity

Control Core provides advanced identity-based security for internal communications through cryptographic workload identity:

• Policy and Control Plane Hardening - What hardening protects, potential effects, and troubleshooting (API keys, SPIRE, deny-by-default)
• Cryptographic Workload Identity - Enterprise-grade zero-trust security with mTLS, automatic certificate rotation, and compliance alignment (SOC 2, ISO 27001, PCI DSS, HIPAA, NIST, FedRAMP)
• Work ID Configuration - Technical setup guide for enabling workload identity

Container Security

Control Core images are hardened to enterprise standards. Runtime images contain no build tools, shell utilities (curl, git, wget), or compilers. All containers run as non-root with dropped capabilities and support read-only root filesystems. The Helm chart enforces Kubernetes Pod Security Standards (restricted profile) by default.

For the full container hardening matrix, see Customer Security Guide — Container Security.

Data Protection

• Data masking: Use policy-driven data masking for sensitive API responses. See Rego Guidelines for masked_response patterns.
• Audit logging: Enable and retain audit logs for compliance. See Audit Logs.
• Secrets: Store database credentials, API keys, and tokens in your platform's secrets manager (e.g., Kubernetes Secrets, AWS Secrets Manager). Never store literal secrets in Helm values files — use secretKeyRef or an external secrets operator.

Supply chain and data plane (SOC 2)

• Supply chain verification — Optional cosign signing, SBOM, and verify steps (CC6.8)
• Data plane hardening — Postgres TLS, Redis TLS+AUTH, backup CronJob (CC6.7 / CC7.5)
• Shared responsibility matrix — Customer vs operator duties for enterprise SOC 2

Monitoring and Compliance

• Audit logs: Review audit logs for unauthorized access or policy changes.
• Health checks: Use Bouncer and Control Plane health endpoints for monitoring.
• License and telemetry: Configure Telemetry for license verification; use encrypted transmission.

Troubleshooting

For more, see the Troubleshooting Guide.

Related Guides

• Cryptographic Workload Identity - Enterprise security and compliance overview
• Work ID Configuration - Technical setup guide
• Administrator Guide - Configuration and user management
• Bouncer Deployment - Securing the policy enforcement layer
• Rego Guidelines - Policy security patterns