​
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:
  • Google
  • 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. Default workload endpoints allow TLS 1.2 or greater with the following ciphers:
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_256_GCM_SHA384
  • TLS_AES_128_GCM_SHA256
When using a Domain the allowed TLS version and ciphers can be customized.

​
Internal

All internal communication between workloads and from workloads to other Control Plane services use mutual TLS (mTLS) with a unique client certificate per workload. Workload client certificates are rotated every hour and utilize TLSv1.2 with the ECDHE-RSA-AES256-GCM-SHA384 cipher.

​
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
  • Workloads in the same GVC as well as specific workloads from other GVCs in the same Org
  • 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, external endpoints can be used to communicate with workloads in other Orgs. 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
    • Project IAM Admin
    • 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.