Architectures to mitigate risk in cloud computing
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:
- High level overview of our approach to security and data privacy
- Low level details about what permissions Coiled needs and what metadata it tracks
But first, three frequently asked questions:
- 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.
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 …
- Asks your cloud provider to set up resources within your cloud account
- Configures security and networking so you can access those resources
- Exits the conversation while you access your data privately
- 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.
However, Coiled does track substantial information about the health of your cluster and computation. This metadata includes information like the following:
- Instance health metrics
- 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 email@example.com.
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.
To operate you provide Coiled with an IAM role with the permissions below.
> IAM Roles (ongoing)
During Setup Coiled needs additional permissions one-time-only. These are below:
> IAM Roles (setup)
See https://docs.coiled.io/user_guide/aws_configure.html for more information.
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
Coiled collects metadata about your resources and computations. Some of this is critical, some is optional. We describe that metadata below:
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 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.
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.
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.