Before users leverage Coiled for productivity, IT and security teams need to review Coiled to ensure everything meets corporate standards, and doesn't introduce undue operational risk.

‍
This document aids this review by providing the following:

‍

1. High level overview of our approach to security and data privacy
2. Low level details about what permissions Coiled needs and what metadata it tracks ‍

‍

But first, three frequently asked questions:

FAQ

• Q: Does Coiled run jobs in Coiled’s cloud account, or mine?
  A: Yours. Coiled jobs run in your cloud account on your behalf.
  
  
• Q: Can Coiled see my data?
  A: No. Not unless you explicitly give it that access, which is rare.
  
  
• Q: So Coiled is 100% safe?
  A: No. Nothing is completely safe. Please read on.

Security Overview

Coiled avoids access to your data and your systems. We serve as a broker between you and your cloud, setting up infrastructure so that you can have a productive and secure experience without relying on Coiled as an intermediary.
‍

Deploy resources within your account

When a user asks for a cluster, Coiled …

‍

1. Asks your cloud provider to set up resources within your cloud account
2. Configures security and networking so you can access those resources
3. Exits the conversation while you access your data privately
4. Tracks health of those resources and ensures that everything cleans up gracefully

‍

Coiled is not present during the conversation when you and your cloud resources access your data. Your data never leaves your internal cloud network.
‍

Data Access Credentials

Coiled’s client software (runs on your machines) ships with functionality to forward your local credentials to your cloud resources after Coiled’s control plane (runs on our machines) exits the conversation.

‍

In this way users have full access to their data on cloud resources without sending credentials through Coiled’s network.
‍

Metadata 

However, Coiled does track substantial information about the health of your cluster and computation. This metadata includes information like the following:

‍

• Instance health metrics
• Logs
• Hardware utilization metrics (CPU, Disk, Memory, Network)
• Dask performance (time spent reading parquet, doing joins, …)
• User code snippets

Some of this metadata is required (like instance health), while other metadata is optional (like code snippets), and still other (logs, hardware utilization) can be configured to live entirely within your own cloud.

‍

By default Coiled collects as much metadata as it can. This helps Coiled staff debug and optimize user workflows, which provides substantial cost savings. We understand that metadata collection is not always acceptable, and so Coiled’s metadata collection is highly configurable.

‍

Professionalism and Physical Security

Coiled is maintained by professional cloud infrastructure engineers and follows best practices. Network communications are secured end-to-end. Sensitive data is encrypted at rest. Access is limited to a few individuals using secure passwords under frequent rotation, multi-factor-authentication, and so on.

‍

Coiled Computing, Inc. is SOC 2 Type II and ISO-27001 compliant. To see evidence of our security certifications, reach out to hello@coiled.io.

Security Details

OK, but exactly what permissions do you need and exactly what metadata do you collect?

‍

Let’s discuss precise IAM roles and metadata. We’ll use AWS terms for things in this document. Please see AWS Setup and GCP Setup for more details.
‍

IAM Roles

Ongoing

To operate you provide Coiled with an IAM role with the permissions below.  

‍

{
    "Statement": [
        {
            "Sid": "Ongoing",
            "Effect": "Allow",
            "Resource": "*",
            "Action": [
                "ec2:AuthorizeSecurityGroupIngress",
                "ec2:CreateFleet",
                "ec2:CreateLaunchTemplate",
                "ec2:CreateLaunchTemplateVersion",
                "ec2:CreateRoute",
                "ec2:CreateSecurityGroup",
                "ec2:CreateTags",
                "ec2:DeleteFleets",
                "ec2:DeleteLaunchTemplate",
                "ec2:DeleteLaunchTemplateVersions",
                "ec2:DeleteSecurityGroup",
                "ec2:DescribeAvailabilityZones",
                "ec2:DescribeImages",
                "ec2:DescribeInstances",
                "ec2:DescribeInstanceTypeOfferings",
                "ec2:DescribeInstanceTypes",
                "ec2:DescribeInternetGateways",
                "ec2:DescribeLaunchTemplates",
                "ec2:DescribeNatGateways",
                "ec2:DescribeNetworkInterfaces",
                "ec2:DescribeRegions",
                "ec2:DescribeRouteTables",
                "ec2:DescribeSecurityGroups",
                "ec2:DescribeSubnets",
                "ec2:DescribeVpcPeeringConnections",
                "ec2:DescribeVpcs",
                "ec2:RunInstances",
                "ec2:TerminateInstances",
                "ecr:BatchCheckLayerAvailability",
                "ecr:BatchGetImage",
                "ecr:CompleteLayerUpload",
                "ecr:CreateRepository",
                "ecr:DescribeImages",
                "ecr:DescribeRepositories",
                "ecr:GetAuthorizationToken",
                "ecr:GetDownloadUrlForLayer",
                "ecr:GetRepositoryPolicy",
                "ecr:InitiateLayerUpload",
                "ecr:ListImages",
                "ecr:PutImage",
                "ecr:UploadLayerPart",
                "ecr:TagResource",
                "iam:GetInstanceProfile",
                "iam:GetRole",
                "iam:ListAttachedRolePolicies",
                "iam:ListInstanceProfiles",
                "iam:ListPolicies",
                "iam:PassRole",
                "iam:TagRole",
                "logs:CreateLogGroup",
                "logs:CreateLogStream",
                "logs:DescribeLogGroups",
                "logs:DescribeLogStreams",
                "logs:GetLogEvents",
                "logs:FilterLogEvents",
                "logs:PutLogEvents",
                "logs:PutRetentionPolicy",
                "logs:TagLogGroup",
                "logs:TagResource",
                "sts:GetCallerIdentity"
            ]
        }
    ],
    "Version": "2012-10-17"
}

‍

Setup

During Setup Coiled needs additional permissions one-time-only. These are below:

‍

{
    "Statement": [
        {
            "Sid": "Setup",
            "Effect": "Allow",
            "Resource": "*",
            "Action": [
                "ec2:AssociateRouteTable",
                "ec2:AttachInternetGateway",
                "ec2:CreateInternetGateway",
                "ec2:CreateRoute",
                "ec2:CreateRouteTable",
                "ec2:CreateSubnet",
                "ec2:CreateVpc",
                "ec2:DeleteInternetGateway",
                "ec2:DeleteRoute",
                "ec2:DeleteRouteTable",
                "ec2:DeleteSubnet",
                "ec2:DeleteVpc",
                "ec2:DescribeInternetGateways",
                "ec2:DetachInternetGateway",
                "ec2:DisassociateRouteTable",
                "ec2:ModifySubnetAttribute",
                "ec2:ModifyVpcAttribute",
                "iam:AddRoleToInstanceProfile",
                "iam:AttachRolePolicy",
                "iam:CreateRole",
                "iam:CreatePolicy",
                "iam:CreateServiceLinkedRole",
                "iam:CreateInstanceProfile",
                "iam:DeleteRole",
                "iam:ListPolicies",
                "iam:ListInstanceProfiles",
                "iam:ListAttachedRolePolicies",
                "iam:TagInstanceProfile",
                "iam:TagPolicy",
                "iam:TagRole"
            ]
        }
    ],
    "Version": "2012-10-17"
}

‍

See https://docs.coiled.io/user_guide/aws_configure.html for more information.

‍

Optionality

Some of these permissions are optional if you are comfortable turning off certain features. For example:

‍

• ECR permissions are only needed if you want Coiled to manage Docker images in ECR for you
• Cloudwatch permissions are only necessary if you want Coiled to track logs

Metadata

Coiled collects metadata about your resources and computations. Some of this is critical, some is optional. We describe that metadata below:

‍

Operational Metadata

We need this information to track and control distributed cloud resources. This operational metadata includes the following:

‍

• Instance health (provisioned, running, closed)

We get this information using the granted IAM roles. These can not be turned off. They are required for operation.

‍

Performance Tracking

Performance metadata helps us debug and optimize workflows with users. Some entries are optional (✅). Others can be moved inside your cloud boundary (➡️) with mild effort on your part.

‍

This data is collected both with Prometheus metrics, and with periodic check-ins with the Coiled control plane over secured web traffic.

Configuration

By default Coiled sets everything up for you and tracks metadata within its own database. Optionally, you can deploy Coiled in more custom cloud environments, and attach metadata storage to your own databases ( ➡️ above). Common configuration choices include the following:

‍

• Bring your own network:  Bring your VPC and subnets, supporting custom network routing and security perimeter for ingress/egress. Limit access to your VPN or corporate network.
• Prometheus: Store metrics in your database for debugging and performance tracking
• Docker: Store user-created images in your private registry (Dockerhub, Artifactory, …)
• Logs: These are stored in your account by default. You can safely disable us having access through IAM permissions.

Final Thoughts

Like any technology, Coiled introduces operational risk. The approach above is designed to minimize risk while providing an easy, rich, and productive experience for users.  

‍

Our experience is that users will take whatever path is easiest, even if that path is insecure and unsanctioned. Coiled crafts an easy and attractive path for all users that is also highly secure and configurable.

‍