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 readLogspermission.
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 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)