Access and security
This page applies to BYOC deployments. To compare the plans, see Deployment models.
Access you grant
To deploy into your account, SubImage needs access to create and manage the deployment's infrastructure. You grant it once, when you connect your account.
- AWS. A CloudFormation stack named
AccountConfigSetupcreates IAM roles in your account. The SubImage control plane assumes these roles through OpenID Connect (OIDC) federation. No long-lived access keys exist. - Google Cloud. A setup script, or the equivalent Terraform, creates service accounts in your project and a workload identity pool that the control plane signs in through. No service account keys exist.
These roles let SubImage manage the cluster, the network, the databases, the storage, and the secrets of your deployment. They are separate from the read-only access that SubImage uses to scan your cloud accounts, which you set up per module.
We recommend a dedicated AWS account or Google Cloud project for the deployment. Then the deployment roles only reach resources that belong to SubImage.
Controls you keep
Two settings in the account setup let you limit what SubImage can do. You set them in the CloudFormation stack parameters or in the Terraform file, and you can change them at any time.
| Setting | Clouds | Effect when off |
|---|---|---|
agent_infrastructure_mutation_enabled |
AWS, Google Cloud | SubImage keeps read-only access to your infrastructure. Upgrades, scaling, and repairs fail until you turn it back on. On Google Cloud, it also removes Kubernetes debug access. |
k8s_debug_access_enabled |
AWS | SubImage cannot reach the Kubernetes API of the cluster to debug the deployment. |
Use the first setting to allow infrastructure changes only during windows you agree with SubImage.
Visibility
Every action SubImage takes in your account goes through the roles above. AWS CloudTrail and Google Cloud Audit Logs record these actions, so your security team can review them like any other activity.
Network
- Users reach the application through an HTTPS load balancer on your domain.
- The databases and the Neo4j servers run in private subnets and accept connections only from the cluster.
- On AWS, the Kubernetes API endpoint is private.
Encryption
- Traffic to the application uses TLS.
- Databases, disks, and buckets are encrypted at rest with your cloud provider's encryption.
- With BYOC with Private Graph, each deployment has its own encryption key for graph backups, and the Neo4j servers use mutual TLS between them.
Secrets
The deployment stores its secrets, such as database passwords, in your cloud secret manager: AWS Secrets Manager or Google Secret Manager. The application reads them from there at runtime.
Agent Sandbox
The AI agent runs commands in an isolated sandbox, on dedicated nodes, under the gVisor runtime. See Agent Sandbox.