Security & IAM reference

This page documents what LakeSail asks for when you connect an AWS account, and why. Your security team should review it before approving a connection. It also serves as LakeSail's customer-facing security disclosure for compliance and procurement reviews. For the step-by-step connection flow, see the Quickstart.

In short

• LakeSail runs in your AWS account. Your data, compute, and clusters stay in your account; they never move to LakeSail.
• LakeSail never holds your credentials. You grant access by creating one IAM role. LakeSail borrows it on demand, so there is no stored key or password it could use or lose.
• You stay in control. Every action LakeSail takes appears in your own CloudTrail, and deleting the role cuts off access immediately.
• Access is tightly scoped. LakeSail can only touch resources it created (named lakesail-*). A permissions boundary makes anything broader structurally impossible.

For the exact IAM policies behind all of this, see the AWS IAM reference.

How a connection works

LakeSail never holds long-lived AWS credentials. A connection has three steps:

1. You deploy a small CloudFormation template (one click from the LakeSail console, or by hand). It creates a single IAM role in your account with a scoped trust policy. Nothing else is created yet: no clusters, no data, just the permission grant.
2. LakeSail assumes that role on demand via sts:AssumeRole, presenting a unique secret (the external ID) each time. Using the role, it provisions and runs your compute (Kubernetes, networking, storage) inside your account.
3. You can revoke at any time by deleting the role or the stack. LakeSail's next access attempt fails immediately.

What the CloudFormation stack creates

The stack provisions two IAM roles and a set of managed policies. The primary role, the cross-account role LakeSail assumes, is the one your security team will care about:

• Name: you choose (parameter IamRoleName).
• Trust policy: allows only the LakeSail platform principal to assume the role, and requires the correct external ID as a sts:ExternalId condition.
• Permissions boundary: a managed policy (lakesail-<connection-id>-RoleBoundary) that caps what the role can ever do, even if a policy is later mis-scoped.
• Explicit Deny policy: prevents anyone from removing or altering the permissions boundary while LakeSail is connected.
• Tags: Service: LakeSail, LakeSail-Connection: <id>, LakeSail-Tenant: <id> for audit in CloudTrail and Cost Explorer.

The second role, lakesail-<connection-id>-CallbackRole, exists only for the CloudFormation lifecycle-notification Lambda; it can only write its own CloudWatch log group and read (describe / drift-detect) its own CloudFormation stack. Both roles are the only new identities the stack creates. No IAM users, no access keys. The callback role's exact (minimal) permissions are in the AWS IAM reference.

AWS infrastructure charges for resources LakeSail provisions in your account are billed by AWS directly to you, separate from your AWS Marketplace transaction with LakeSail.

The trust policy installed on the role:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::921150455437:root" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "<YOUR_EXTERNAL_ID>"
        }
      }
    }
  ]
}

arn:aws:iam::921150455437:root is LakeSail's stable production control-plane account; it reaches the trust policy through the LakeSailPrincipal parameter. <YOUR_EXTERNAL_ID> is a UUIDv4 generated server-side per connection and shown to you only once. It is rotatable: revoke a connection in the LakeSail console and the corresponding external ID is invalidated immediately.

The complete JSON for every policy below is published verbatim on the AWS IAM reference page.

AWS services LakeSail provisions in your account

Every resource is named with the prefix lakesail-<connection-id>-* and tagged with Service: LakeSail and LakeSail-Connection: <id>, so you can audit and revoke it at any time. These are created at runtime by the assumed role over the life of the connection; the CloudFormation stack itself only creates the IAM roles, policies, and the lifecycle Lambda described above. The exact per-resource configuration lives in the AWS IAM reference; this is the plain-language inventory of what gets created and why.

• IAM: the cross-account role, the two permissions boundaries, and the scoped roles your pods and nodes run as (for cluster operation, storage, logging, and autoscaling). These pod and node roles use IRSA, the standard mechanism for giving Kubernetes workloads narrow AWS permissions, backed by one OIDC identity provider per cluster.
• EKS: one managed Kubernetes cluster per workspace, private by default and with audit logging on, plus its standard add-ons and a small system node group.
• EC2 / VPC: the network your clusters run in. If LakeSail creates it, that is a VPC with public and private subnets, gateways, route tables, and security groups; for bring-your-own-VPC, LakeSail tags and reuses what you already have.
• S3: one workspace bucket per network (lakesail-<connection-id>-<network-id>-ws), encrypted with KMS, with public access blocked and retain-on-delete so an accidental disconnection never destroys your data.
• Glue: one AWS Glue (the AWS data catalog) database per LakeSail catalog.
• CloudWatch Logs: one log group per cluster for the EKS control-plane audit logs.
• SSM Parameter Store: encrypted parameters holding the TLS material for Konnectivity, the encrypted control-plane-to-node tunnel in EKS.
• ACM: one TLS certificate per cluster for the network load balancer (NLB) that fronts your Sail sessions.
• Lambda: one small function used only to notify LakeSail when the stack is created, updated, or deleted.

The template's parameters, the role name you choose plus the read-only values LakeSail pre-fills for your connection, are listed in the AWS IAM reference.

Permissions granted

Permissions follow the principle of least privilege. Each managed policy is scoped as tightly as possible; actions are scoped either by ARN pattern (lakesail*<connection-id>*) or by tag condition (aws:ResourceTag/LakeSail-Connection=<connection-id>), with a small number of exceptions where AWS does not support resource-level scoping (eks:CreateCluster, s3:ListAllMyBuckets, iam:CreateOpenIDConnectProvider, kms:CreateKey, the Service Quotas read actions, pricing:GetProducts). Where broader rights are needed, the permissions boundary caps the effective reach.

The full IAM policy statements for each of the managed policies below are published verbatim on the AWS IAM reference page. You can also generate a pre-filled CloudFormation template from Settings → Cloud Accounts → Add AWS Account → Advanced → Download Template in the LakeSail UI; the policy bodies are identical.

EKS (PolicyEKS)

Create and manage EKS clusters, node groups, add-ons, access entries, and pod identity associations. Required because LakeSail provisions the Kubernetes cluster that runs your compute.

Auto-scaling (PolicyAutoScaling)

Manage EC2 instances, launch templates, and auto-scaling groups. Required for Karpenter (the Kubernetes node autoscaler) to scale compute nodes in response to job demand.

Networking, read + tag (PolicyNetworkReadAndTag)

Read-only access to EC2 and ELB, plus the ability to tag resources. Used to discover existing VPC state and mark resources with the LakeSail tags above.

Networking, compute (PolicyNetworkCompute)

Create and modify load balancers and target groups. Required for cluster endpoints.

Networking, manage (PolicyNetworkManage)

Create and modify EC2 resources, scoped by ARN pattern to resources whose names match the LakeSail pattern. LakeSail cannot modify your other VPC resources. The CloudFormation network defines well-defined public and private subnet boundaries that isolate application services from access to data stores.

IAM + CloudWatch (PolicyIAMAndCloudwatch)

Create and manage IAM roles and policies scoped to the LakeSail role namespace (lakesail*), and write to CloudWatch Logs. The IAM scope means LakeSail can only manage IAM objects related to clusters it provisioned; it cannot touch arbitrary roles in your account. iam:CreateRole for workload roles is conditioned on the LakeSail permissions boundary being attached, so LakeSail-created workload roles cannot escalate.

CloudFormation, observability + identity (PolicyCloudFormationAndObservabilityAndIdentity)

Read CloudFormation stacks and manage the connection's own stack, emit and read cluster metrics, read the Pricing and Service Quotas APIs for cost attribution and preflight checks, manage the connection role and the callback Lambda, and call sts:GetCallerIdentity for identity verification.

S3 + Glue for workloads (WorkloadBoundary)

Full S3 access, restricted by the workload boundary to buckets matching lakesail-<connection-id>-* and lakesail-<connection-id-lower>-* patterns. Used for workspace data, job artifacts, and the default Glue catalog.

Permissions boundary

Two AWS-managed permissions-boundary policies are installed alongside the role:

• RoleBoundary is attached to LakeSailRole itself. It restricts the role to a fixed allow-list of service namespaces (EKS and EKS Auth, EC2, ELB, Auto Scaling, IAM, Logs, KMS, CloudWatch, CloudFormation, STS, SSM, Glue, S3 and S3 Express / Tables / Vectors, SSM Messages, EC2 Messages, ECR, Service Quotas, Pricing, ACM, Lambda). Anything outside these namespaces (DynamoDB, RDS, SageMaker, IAM Identity Center, Organizations, etc.) is denied even if the per-action policies were ever miswritten.
• WorkloadBoundary is attached to every IAM role LakeSail creates for pods and nodes. It allows S3 data-plane actions, ECR pull, CloudWatch Logs, and glue:*, and nothing else.

A second, explicit-deny policy prevents anyone (including the role itself) from removing the boundary or modifying the role's policies while the connection is active. Boundary modification through any path other than CloudFormation stack update is structurally denied.

What LakeSail cannot do

• Assume the role without the external ID recorded at connection time.
• Modify IAM roles or policies not created by the LakeSail connection.
• Access S3 buckets outside the lakesail-<connection-id>-* naming pattern.
• Read from or write to your VPC resources not matching the LakeSail ARN pattern.
• Remove its own permissions boundary (explicit Deny).
• Attach the AWS-managed AdministratorAccess policy, or any other over-broad managed policy, to anything in your account. The boundary's allow-list makes this structurally impossible.

Tenant isolation

LakeSail isolates each customer's data and environment so that no other customer can access them, unless the customer explicitly permits access.

Because each tenant's compute and data live in their own AWS account, cross-tenant access is structurally impossible at the account boundary. LakeSail's control plane holds no customer data. LakeSail assumes the per-customer cross-account role only when actively servicing that customer. No shared compute, no shared storage, no shared network across tenants. Sensitive customer data and public metadata are kept in distinct data classes: customer data lives in the workspace S3 bucket inside the customer's account; the LakeSail control-plane database holds only account metadata, configuration, and operational telemetry.

Authentication

LakeSail authenticates all customers before granting access to customer data. Customer access to the LakeSail platform is gated on your identity provider (OIDC). Cross-account AWS access is gated on sts:AssumeRole with your unique external ID. No anonymous access is permitted, and all programmatic access uses IAM roles with no hard-coded credentials in scripts, headers, or source code.

Encryption

LakeSail uses industry-standard means of encryption to protect customer data in transit and at rest.

In transit. All control-plane traffic between LakeSail and your cluster runs over a single outbound mTLS tunnel using TLS 1.2 or higher. Client connections to Sail workloads terminate at the session-proxy NLB using a per-cluster ACM certificate. The CloudFormation callback uses HTTPS with HMAC-SHA256 signatures keyed on the external ID. EKS bearer tokens are presigned via STS GetCallerIdentity and are short-lived.

At rest. The workspace S3 bucket uses KMS server-side encryption with the AWS-managed aws/s3 key. EKS control plane secrets and etcd are encrypted at rest by AWS-managed defaults. Konnectivity TLS material is stored as SecureString in SSM Parameter Store, encrypted with the AWS-managed aws/ssm key. LakeSail's control-plane databases are encrypted with AWS-managed KMS (AES-256).

Key rotation. AWS-managed KMS keys used by LakeSail-provisioned infrastructure follow AWS's scheduled key-rotation defaults. Customer-managed KMS keys you provide follow your own rotation schedule. ACM certificates are renewed automatically before expiry.

Vulnerability management

The product is free of known vulnerabilities, end-of-life software, malware, and other malicious code at the time of publishing. LakeSail performs authenticated dependency and container scanning across the SDLC pipeline and remediates issues on a published cadence: critical vulnerabilities within 14 days, high within 30 days, medium within 60 days, measured from public disclosure of a patch (for third-party vulnerabilities) or from internal confirmation (for first-party vulnerabilities). Post-publication issues identified after listing are patched on the same cadence. Full terms are in the Security Addendum.

Data handling

Topic	LakeSail's practice
Collection	We collect account metadata (subscription state, configuration, billing usage), workload metadata (job IDs, cluster ARNs, resource configuration), and operational telemetry (Sail engine error messages, performance metrics). We do not collect or access query results, table contents, intermediate compute data, or pod logs.
Storage	Customer data (files, query results, intermediate state) stays in your AWS account at all times. LakeSail control-plane metadata lives in our us-east-1 AWS account.
Usage	Account metadata is used to operate, secure, and bill the service. We do not train models on customer data and do not sell or share customer data for marketing.
Sharing	For LakeSail's AWS deployment, AWS is the cloud infrastructure provider for the application plane. Customer data stays in your AWS account; LakeSail does not process Customer Content outside the boundary documented on this page. The full list of third-party subprocessors LakeSail uses for its own operations is at lakesail.com/legal/lakesail-subprocessors.
Retention	Customer data in your account is retained at your discretion; we do not delete or modify it. Control-plane metadata is retained for the term of the agreement and any period required by law. LakeSail deletes customer data on customer request within the timeframe defined in the EULA.
Backup	LakeSail does not back up Customer Content (it lives in your AWS account; backup is your responsibility). LakeSail's own control-plane database is backed up daily via AWS-managed RDS automated backups.

See the full Privacy Notice, Data Processing Addendum, Subprocessor list, and Security Addendum for contractual terms.

Shared responsibility

Area	LakeSail	You
Control-plane availability, patching, and security	✓
Cross-account role permissions-boundary enforcement	✓
Workspace S3 bucket encryption defaults	✓
Control-plane audit-log retention (≥ 1 year) and tamper-protection	✓
Routinely scheduled incident-response exercises	✓
Control-plane recovery time / point objectives	✓
Vulnerability scanning and patching of LakeSail-managed infrastructure	✓
EKS cluster patching (managed by EKS)	shared	shared
Customer-side CloudTrail log retention and protection	shared	shared
Network ingress/egress policy on the BYOC VPC	shared	shared
Customer data lifecycle (versioning, retention, deletion, backup)		✓
AWS account security (root MFA, IAM users, SCPs)		✓
Audit log review in CloudWatch		✓
Revoking the cross-account role if needed		✓

LakeSail conducts incident-response tabletop exercises on a quarterly cadence. The recovery time objective (RTO) for the LakeSail control plane is 24 hours; the recovery point objective (RPO) is one hour. Customer-side disaster recovery for data in the workspace S3 bucket is the customer's responsibility (S3 versioning and cross-region replication are available; LakeSail does not configure them on your behalf).

Rotating or revoking access

• Rotate: delete the CloudFormation stack and redeploy it with the same connection ID. The trust policy is re-established atomically; no downtime if done quickly.
• Revoke: delete the stack. LakeSail's next AssumeRole call fails, which surfaces as the cloud account moving to disconnected / failed in the UI. Any dependent networks and clusters are frozen until the connection is repaired or deleted. See Troubleshooting for the errors a broken trust surfaces.

Audit

LakeSail enables audit logging of security-relevant events when the product processes customer data, and consolidates those logs across the control plane.

Every LakeSail action inside your account is a role-assumed API call, which shows up in CloudTrail with:

• userIdentity.sessionContext.sessionIssuer.userName = your role name.
• Session name prefixed with lakesail-.
• Resources tagged with Service: LakeSail and the connection/tenant IDs above.

Filter CloudTrail on your role name to see every action LakeSail has taken, with timestamps and caller session.

LakeSail-side audit logs covering the control plane are retained for at least one year and protected from tampering through write-once log storage and IAM controls that prevent deletion. CloudTrail in your account is retained per your account's log-group retention policy; we recommend at least one year and tamper-protection via SCP or a dedicated log-archive account.

Security incident reporting

To report a security incident, vulnerability, or suspected breach, email support@lakesail.com with [SECURITY] in the subject line. We acknowledge inbound reports within one business day and provide a status update within five business days.

If LakeSail becomes aware of a security incident that may be relevant to a customer, LakeSail will notify impacted customers without undue delay, in accordance with the Data Processing Addendum and the Security Addendum.

Compliance posture

LakeSail's product complies with applicable local laws and regulations including the General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA). GDPR is addressed through the Data Processing Addendum, which includes Standard Contractual Clauses for international data transfers. CCPA obligations are covered in the Privacy Notice and Supplemental Privacy Notice for California Residents.

LakeSail is committed to achieving SOC 2 Type II compliance; the report will be available to subscribers under NDA when complete. HIPAA, PCI, and FedRAMP are not in scope for the current platform.

For specific compliance questions, contact support@lakesail.com.

Manual deployment

If you prefer not to use the one-click launch:

1. In LakeSail, open Settings → Cloud Accounts → Add AWS Account, expand Advanced, and click Download Template. The template is pre-filled with the correct parameter values for your connection.
2. Apply it through the AWS Console, aws cloudformation deploy, or your IaC tool.
3. Copy the resulting role ARN from the stack's Outputs tab.
4. Paste it back into LakeSail and click Verify Connection.

The manual path and the one-click path produce an identical role. The template is the source of truth.

API reference

• Cloud accounts: GetExternalConnectionTemplate for the template, CreateExternalConnection to record an ARN, VerifyExternalConnection for the assume-role check.