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:

• Google
• Github
• Microsoft

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. After the token modal is dismissed, the token will no longer be available to be displayed or retrieved and will need to be regenerated if lost or compromised.

Authorization

Authorization to all Control Plane resources is controlled using fine-grained authorization policies assigned to the following principal types:

• Users
• Groups
• Service Accounts
• Workload Identities

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 (https://jose.readthedocs.io/en/latest/).
• 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 60 days.

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 Provider (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

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.