Security
Authentication and Authorization
User Accounts
Access to the Control Plane console or CLI is granted by authenticating using single sign-on (SSO) to one of the following providers:
- Github
- Microsoft
- Security Assertion Markup Language (SAML)
For your chosen provider, Multi-Factor Authentication (MFA) is recommended.
Service Accounts
Access to the Control Plane CLI using a Service Account is granted by the use of a generated token. During the token generation, the token can be copied to the clipboard or downloaded. Once the token modal is dismissed, the token will no longer be available for display or retrieval. If the token is lost or compromised, it must be regenerated.
Authorization
Authorization to all Control Plane resources is controlled using fine-grained authorization policies assigned to the following principal types:
Certificates
External
All communications from external sources use end-to-end TLS to the destination Workloads.
The server certificates are generated by Let’s Encrypt and are rotated every 60 days.
Internal
All internal communications use mutual TLS (mTLS) using client certificates.
These certificates are rotated every hour.
Firewall
Control Plane uses industry-standard firewall technology. All Workloads are configured to be fully restricted with no internal or external communication enabled by default, except for internal health check monitoring.
External
Inbound access to a Workload can be enabled/disabled from the entire Internet or limited to a specific list of CIDRs.
Outbound access from a Workload can be enabled/disabled to the entire Internet or limited to a specific list of CIDRs or hostnames.
Internal
By default, the Workload’s internal firewall is disabled.
Each Workload can be configured to allow inbound communications from:
- Workloads in the same GVC
- Workloads in the same Org
- Specific Workloads
- Allow to access itself (enable replicas of a Workload to access other replicas)
Network Resource Access
Network resource access via agents (configured within a Workload Identity) is implicitly allowed through the firewall.
Workload Access
- The internal Kubernetes API access is restricted from all Workloads by multiple firewall levels.
- No Kubernetes access tokens are available to the Workloads.
- Access to kernel system calls is filtered using gVisor which provides an isolation boundary between the application and the host kernel.
- Workloads can communicate with:
- The Control Plane metadata service which provides short-lived cloud credentials based on the identity of the Workload.
- The Control Plane audit service.
GVC Isolation
Every Workload receives discovery information for other Workloads across the Org but communication is disabled by default using firewalls and client certificate validation.
Workload Isolation
All Workloads are isolated at the Org level based on the use of:
- Host-based Firewalls
- Client Certificates
- Proxies
Direct communications between containers residing in other Orgs are not possible. Isolation between Workloads within an Org is defined based on the Workloads’ internal firewall configuration.
Container Isolation
Containers are isolated by the use of:
- cgroups
- Namespaces
- Restricted Syscalls
- Restricted Capabilities (groups of syscalls)
Headers
The following headers are sanitized and replaced with valid content before being forwarded to running Workloads:
- x-envoy-external-address
- Used to verify the source address of the external requestee.
- x-forwarded-client-cert
- Used to verify that communications between Workloads were made using mTLS and to verify the identity of the requesting Workload.
- x-forwarded-for
- x-forwarded-proto
- x-request-id
- referer
Identity Cloud Access
Amazon
- Leverages AWS roles and policies to create least privileged, short-lived tokens that are assigned to Workloads during startup.
- Network traffic between Control Plane and the AWS API is over a TLS connection.
- During the creation of a Cloud Account targeting AWS, a policy within an AWS account is created that allows the Control Plane AWS account the ability to perform the following actions:
- iam:CreatePolicy
- iam:UpdateAssumeRolePolicy
- iam:DetachRolePolicy
- iam:TagRole
- iam:UpdateRoleDescription
- iam:DeletePolicy
- iam:CreateRole
- iam:DeleteRole
- iam:AttachRolePolicy
- iam:UpdateRole
- iam:PutRolePolicy
- iam:TagPolicy
Azure Connector
- Leverages Azure Function Apps to create least privileged, short-lived tokens that are assigned to Workloads during startup.
- Network traffic between Control Plane and the Azure Function App endpoint is over a TLS connection and the request body is signed and encrypted using JOSE.
- The Function App is assigned the owner role within the Azure subscription. Users with permissions to create/update Workloads identities have the ability to assign any scope and roles within the subscription.
Google Cloud
- Leverages GCP Service Accounts to create least privileged, short-lived tokens that are assigned to Workloads during startup.
- Network traffic between Control Plane and the GCP API is over a TLS connection.
- During the creation of a Cloud Account targeting GCP, the Control Plane GCP Service Account is added to a project and granted the following roles:
- Viewer
- Service Account Admin
- Service Account Token Creator
Data Security
Log Access and Retention Policy
All logs generated by an Org are only accessible by a user having the readLogs permission.
Logs are retained for 30 days by default.
Rentention settings for logs, metrics and traces can be adjusted on the Org.
Secrets
Org secrets are encrypted at rest using envelope encryption and use TLS while in transit. Secrets are stored on multiple cloud providers using cloud-based Hardware Security Modules (HSM).
Platform Security
Vulnerability Policy
Security updates and patches are applied regularly and meet all compliance and regulation requirements.
For zero-day vulnerabilities, updates are applied as soon as they are available and verified.
All scheduled maintenance that could cause downtime will be communicated via email and Discord.
If you find any security issues, or have any security questions, please email secops@controlplane.com.
Compliance
Data Centers
The Control Plane platform is hosted at the following providers:
- Amazon via Amazon Web Services (AWS)
- Google via Google Cloud Platform (GCP)
- Microsoft via Azure
Each provider complies with the following:
- Sarbanes-Oxley (SOX)
- ISO 27001
- SOC 1 and SOC 2/SSAE 16/ISAE 3402 (Previously SAS 70 Type II)
- PCI Level 1 AWS, Azure, GCP
- FISMA Moderate
Payment Processing
Stripe is used to encrypt and process credit card payments. Stripe is PCI Service Provider Level 1 compliant.
Privacy
Control Plane is committed to customer privacy. Review the privacy policy here.
Support staff has access to the following:
- Infrastructure support staff have access to monitor Workload activity to maintain the stability of the platform.