Cloud connector setup guide

How to connect AWS, Azure, Google Cloud, Kubernetes and other VPS providers to 10ETLabs: what you create in your account, which permissions it grants and why, what we collect, what we never touch, and how to fix every setup error the console can show.

Every connection is read-only. 10ETLabs never creates, changes or deletes anything in your accounts through a connection, and never reads data (objects, rows, secrets, prompts, model weights).

Read-only by default. Fixes are code you review, or — only if you deploy a separate remediator role — one-click changes you approve. See remediation.md.

How a connection works

1. Set up access. You create a read-only identity in your account (an IAM role, an app registration, a service account, a Kubernetes service account or a vendor API token). The console's wizard offers one or more setup methods per provider, with the recommended one first.
2. Connect. You paste the values into the wizard. The format of each value is checked as you type. Test connection signs in and runs one read per service the scan needs, and shows a checklist:
   • ✓ passed
   • ⚠ warning: the scan can still run, but that service is skipped and shown as a coverage gap until you fix it
   • ✗ failed: a scan cannot run until this is fixed
   • – skipped: not applicable (for example a service with no endpoint in your home region)
3. Verify and scan. Saving stores the credentials encrypted (AES-256-GCM, never returned to the browser, never logged). Verify access runs the same checklist against the saved credentials, then Start first scan collects inventory and findings.

Coverage gaps. When one read fails during a scan (a permission removed, throttling, a disabled API), the scan records a *collection finding* and a *coverage gap* for that scope instead of failing. Assets and findings inside a gap are kept exactly as they were, so a missing permission never looks like everything was deleted or fixed.

Progress is saved. If you leave the wizard, it reopens at the same step. Secrets are never saved in the browser, so paste them again after a resume.

AWS

What you create

One IAM role, 10ETLabsReader, in each account you want scanned. It trusts only the 10ETLabs platform account (arn:aws:iam::<platform account ID>:root) and only when the caller presents your connection's External ID (sts:ExternalId condition), which protects against the confused-deputy problem. The wizard shows both values.

Setup methods (all create the same role and the same permissions):

When the quick-create link is not offered, the deployment does not publish its templates in S3; download the template and create the stack from the CloudFormation console instead (Create stack → Upload a template file, stack name 10ETLabsReader, then paste the two parameters).

Permissions and why

• SecurityAudit (AWS managed, read-only). Used by the optional Prowler checks.
• TenetLabsCollectorRead (inline): every API call the 10ETLabs collectors make, listed explicitly so a scan never depends on what AWS adds to or removes from SecurityAudit. A test in the codebase (packages/cloud-aws/src/iam-actions.spec.ts) fails if a collector calls an API the templates do not grant.

Never accessed: S3 objects, database rows, EBS snapshots, secret values (secretsmanager:GetSecretValue), KMS decrypt, API key values, model invocation, prompts or outputs.

What is collected

Account and enabled regions; IAM users, roles and their attached/inline policy risk; S3 buckets (publicity, encryption); EC2 instances, security groups, EBS volumes; RDS instances; EKS clusters; ECR repositories; Lambda functions and function URLs; API Gateway REST APIs; CloudTrail status; SageMaker notebooks and endpoints (with their models); Bedrock custom models, provisioned throughput, guardrails, invocation logging, agents (action groups, knowledge bases) and knowledge bases (data sources).

Scans run 4 regions and 2 member accounts at a time (AWS_REGION_CONCURRENCY, AWS_ACCOUNT_CONCURRENCY), every listing is paginated, SDK calls retry throttling adaptively (8 attempts) with 30-second request timeouts, and assumed-role sessions are refreshed before their one-hour expiry.

AWS Organizations

Connect the management account (or a delegated administrator) and 10ETLabs lists every active member account (organizations:ListAccounts; suspended or closing accounts are skipped). For each member it assumes arn:aws:iam::<member>:role/<same role name> with the same External ID, directly from the platform account. So:

1. Deploy the CloudFormation template to every member account as a StackSet (CloudFormation → StackSets → Create StackSet, service-managed permissions, deploy to your organization or OUs) with the same ExternalId and PlatformAccountId parameters and the default role name.
2. Deploy the stack in the management account too (StackSets do not deploy to the management account), and connect it.

A member account without the role appears as a "Member account was not assumed" collection finding and a coverage gap; the rest of the organization is still scanned.

Known limitations

• AWS GovCloud (US), China and ISO partitions are not supported; the wizard refuses their ARNs.
• CloudTrail is read from us-east-1 (home trails plus shadow copies of multi-region trails). A single-region trail whose home region is elsewhere is not listed, so an account with only such trails is reported as having no multi-region trail (which is still true).
• Member accounts must use the same role name and External ID as the connected account.

Troubleshooting

Azure

What you create

An app registration (service principal) named 10ETLabs Reader with a client secret, assigned the built-in Reader role on each subscription you want scanned, and (for Entra ID) four read-only Microsoft Graph application permissions with admin consent. You paste the Directory (tenant) ID, Application (client) ID and the secret Value.

An ARM template (10etlabs-azure-reader-assignment.json) is also available to assign Reader on one subscription for an existing service principal: az deployment sub create --location <region> --template-file 10etlabs-azure-reader-assignment.json --parameters principalId=<object ID>. The principalId is the Enterprise application object ID, not the app registration's.

Whoever runs the setup needs permission to register applications and Owner or User Access Administrator on the subscriptions. Granting admin consent for the Microsoft Graph permissions needs a Global Administrator or Privileged Role Administrator; anyone else can request them and ask an admin to click Grant admin consent later (App registrations → 10ETLabs Reader → API permissions). The ARM template cannot grant Graph permissions; use the portal step for them.

Permissions and why

• Reader (built-in role acdd72a7-3385-48ef-bd42-f606fba81ae7) on each subscription: lists resource configuration through Azure Resource Graph. Reader cannot read storage data, Key Vault secrets, keys or certificates, or change anything.
• The AI supply-chain reads are ARM GETs under the same Reader role: model deployments and content filters (RAI policies), Foundry projects and connections, Azure ML datastores, online endpoints and deployments, model, job, data and environment versions, compute instances, diagnostic settings, blob container access levels, and the role assignments and role definitions of workload managed identities. AI Search index, indexer and data source *definitions* are read on the search data plane with an Entra ID token for the same app; Reader covers them when the service has role-based access enabled. No extra role is needed, and none that can invoke a model (such as Cognitive Services OpenAI User or Azure AI User) is ever requested.
• Never called: listKeys, connection listsecrets, datastore listSecrets, the Azure OpenAI data plane (files, fine-tuning jobs, completions), the Foundry agent (Assistants) APIs, and AI Search document reads.
• Reader also covers Microsoft.Authorization/*/read: role assignments, role definitions and deny assignments, used for effective permissions. Nothing extra is needed on Azure resources.

Entra ID (Microsoft Graph)

Application permissions on Microsoft Graph, all read-only, granted with admin consent:

Test connection reads the permissions actually granted (the roles claim of a Graph token) and lists each one: missing ones are warnings with the exact fix, and the scan then records those areas as coverage gaps. Features your license does not include are not errors: without Entra ID P2 there is no PIM, so every active admin assignment is permanent; without P1 there is no Conditional Access or sign-in activity. Graph paging (@odata.nextLink, only followed on graph.microsoft.com) and throttling (429 with Retry-After) are handled. Large directories are read up to 20,000 users, groups and service principals and 5,000 app registrations; beyond that the rest is a coverage gap.

Effective permissions

For every subscription, 10ETLabs reads role assignments at, above and below it (management groups, the subscription, resource groups and resources), role definitions (built-in and custom) and deny assignments. Each assignment is resolved into what it allows: actions minus notActions and dataActions minus notDataActions, tested against concrete operations (manage resources, Microsoft.Authorization/roleAssignments/write, list storage keys, write or read blob data, read Key Vault secrets, VM run command). Group assignments are expanded through transitive membership (up to 300 groups and 5,000 members each), and capabilities a deny assignment covers are removed. Assignments with an ABAC condition are shown but never treated as conclusive. The Identity tab shows, for each principal, the chain behind its access: *member of group → role → scope → what it allows*.

Managed identities are linked to the VM, Azure OpenAI or AI services account they belong to (the resource's identity block), so attack paths can follow *internet-exposed VM → managed identity → role assignment → subscription Owner or storage data*. A path is built only when every hop was read: the NSG / NIC / public IP evaluation that shows the exposure, the identity link, and the assignment and definition that grant the access.

Identity checks

What is collected

Every subscription the app can read, and one Azure Resource Graph query per subscription (Resources, 1,000 rows per page, all pages, including each resource's managed identity): virtual machines and their NICs, public IPs, subnets and network security groups; storage accounts (public blob access, HTTPS-only, TLS version, shared-key access, public network access); Key Vaults (purge protection, public network access); SQL servers (public network access, minimum TLS); AKS clusters (API server exposure, RBAC, local accounts); Azure OpenAI and Cognitive Services accounts (public network access). Requests time out after 30 seconds and throttling (429) is retried with backoff that honours Retry-After.

AI supply chain (only for subscriptions with AI resources): each model deployment with its model, version, SKU and content filter; each Azure ML online endpoint with its network access, auth mode and managed identity, and per deployment the registered model version (artifact storage account and container, resolved through datastores), the job that produced it (the storage accounts and containers its inputs read, including data assets) and the serving image registry; compute instances (public IP, public SSH, idle shutdown, identity); Foundry and ML connections (category, target, auth type; never credentials); AI Search indexes with each indexer's data source type and container; diagnostic settings; the public access level of blob containers the AI estate reads (only on accounts that allow public blobs); and the role assignments of each workload managed identity (Owner, Contributor or role-assignment rights at subscription or resource-group scope). Every failed read is a coverage gap for service ai. Requests time out after 30 seconds and throttling (429) is retried with backoff that honours Retry-After.

Disabled or deleted subscriptions are skipped and recorded as a coverage gap (their inventory is kept). Azure role assignments, role definitions and deny assignments are read per subscription, and Entra ID through Microsoft Graph (see above); a read that fails there is a coverage gap for that area, never a failed scan or a false finding.

Known limitations

• Azure public cloud only (login.microsoftonline.com, management.azure.com). Azure Government and Azure China are not supported.
• Client secrets only (no certificate or federated credential sign-in). Secrets expire (the script creates a one-year secret); create a new one before expiry and update the connection.
• SQL firewall rules are not collected.
• Azure OpenAI fine-tuning jobs and uploaded training files live on the OpenAI data plane, which needs a role that can also invoke models. They are not read, so a fine-tuned deployment is marked as fine-tuned but not linked to its training data. Foundry agents (Assistants API) are not collected for the same reason.
• AI Search data sources never return their connection string to a Reader, so an index is linked to its source container name and type, not to a storage account. AI Search services that accept API keys only are a coverage gap (keys are never used).
• Effective permissions cover Azure RBAC and Entra ID directory roles. Microsoft Graph API permissions granted to apps, administrative-unit scoped roles, Azure AD B2C tenants and per-user (legacy) MFA are not evaluated.
• Management-group hierarchy is taken from the assignments each subscription returns (Reader on subscriptions does not list management groups).

Troubleshooting

Google Cloud

What you create

A service account 10etlabs-reader in the project, with four predefined read-only roles, and a JSON key for it. The Cloud Asset and Resource Manager APIs are enabled; the Vertex AI and Notebooks APIs are left as they are (if they are off, Vertex AI is not in use and there is nothing to scan).

In the wizard, drop or paste the key file; the wizard shows the detected service account and project. Leave Project ID blank to scan the key's own project, or enter another project where the service account has the roles.

Permissions and why

APIs: Cloud Asset API (cloudasset.googleapis.com) and Cloud Resource Manager API (cloudresourcemanager.googleapis.com). If the service account lives in a different project from the one scanned, the Cloud Asset API must also be enabled in the service account's project (quota is charged there).

No basic role (Viewer, Editor, Owner) is needed. The OAuth scope is cloud-platform.read-only. A test in the codebase (packages/cloud-gcp/src/permissions.spec.ts) records every Google API URL the collector and verify request and fails if one needs a permission the templates' roles do not grant.

Never accessed: objects in buckets, BigQuery or database data, Secret Manager values, Vertex AI dataset items, RAG file contents, model prompts, predictions, outputs or weights. No model is ever invoked.

What is collected

Project IAM policy (service accounts with Owner/Editor); Compute Engine instances (external IPs) and VPC firewall rules; Cloud Storage buckets (public access prevention, uniform access, bucket IAM for allUsers / allAuthenticatedUsers); GKE clusters; Cloud SQL instances; IAM service accounts and user-managed keys. Listings are paginated (500 per page), requests time out after 60 seconds and 429/5xx are retried.

Vertex AI supply chain. One Cloud Asset listing (aiplatform.googleapis.com.*, notebooks.googleapis.com.*) finds the locations in use; only those are read through the Vertex AI API ({location}-aiplatform.googleapis.com, 100 per page) and the Notebooks API v2. Each model is linked to its artifact bucket, serving image repository and the job that produced it; each training pipeline, pipeline job or tuning job to its input buckets and BigQuery datasets; each endpoint to its deployed models and service accounts; each Vector Search index and RAG corpus to its source bucket; each Agent Engine deployment to its package bucket. Endpoint, Artifact Registry repository and BigQuery dataset IAM policies come from Cloud Asset Inventory (allUsers / allAuthenticatedUsers). Custom jobs are not listed on their own: only jobs a model names are read. A location or collection that cannot be read (denied, API disabled, not offered in that region) is a coverage gap for service vertex; nothing there is deleted or resolved.

Known limitations

• One project per connection. Folder and organization scope are not supported yet; connect each project.
• Service account JSON keys only. Workload identity federation configurations ("type": "external_account") are not supported yet.
• Organizations created since 2024 enforce iam.disableServiceAccountKeyCreation by default. Key creation then fails; an organization policy administrator must allow keys for this project.

Troubleshooting

Kubernetes

What you create

Apply one manifest (kubectl apply -f 10etlabs-k8s-reader-clusterrole.yaml). It creates:

• ClusterRole 10etlabs-reader with only list on nodes, pods, services (core) and deployments (apps)
• ServiceAccount kube-system/10etlabs-reader and a ClusterRoleBinding to the role
• Secret kube-system/10etlabs-reader-token of type kubernetes.io/service-account-token: a long-lived token (tokens from kubectl create token expire after an hour and scans would then fail)

Then paste into the wizard:

The CA certificate is needed for EKS, GKE, AKS and most self-managed clusters, whose API server certificate is signed by a private cluster CA. TLS is verified against it. "Skip TLS verify" exists for lab clusters and is refused in production.

What is collected

Nodes (external IPs, provider ID), services (public LoadBalancers and external IPs, label selector, internal load-balancer annotation), deployments and pods with a security summary of their pod spec: namespace, node, owning workload, labels, service account and whether its token is automounted, host namespaces, hostPath paths, runAsNonRoot/runAsUser, and per container the image reference, privileged, whether CPU/memory limits are set and how many GPUs it requests. The summary feeds the admission-policy simulate view and runtime attack paths (runtime.md). Lists are paginated (limit=500 with continue); each request times out after 30 seconds (KUBE_REQUEST_TIMEOUT_MS). A kind that cannot be listed becomes a coverage gap; if none can be listed the scan fails.

Never accessed: Secrets, ConfigMaps, pod logs, exec, port-forward, etcd. Note that listing pods returns full pod specs, including literal environment variable values; 10ETLabs keeps only the fields above (never env, args, commands or annotations).

Optional: runtime sensor and admission policy

Everything above is agentless. For runtime evidence (shells in model servers, instance-metadata access, unexpected egress, miners, risky pods actually running) and deploy-time blocking, you can add an optional Helm chart from Findings → Cloud → Runtime (or the link on the Kubernetes connection). It uses its own per-cluster key (hashed at rest, rotate/revoke in the console) and signed HTTPS requests, sends metadata only, and the admission webhook fails open by default. See runtime.md for what it collects, what it never collects, resource use and troubleshooting.

Network and SSRF protection

The API server URL must be https://. Every request resolves the host, rejects private, loopback, link-local and metadata addresses (unless the deployment is on-prem or hybrid), pins the connection to the vetted IP and never follows redirects, so the token cannot be sent elsewhere. A cluster whose API endpoint is private-only cannot be scanned from the SaaS console.

Troubleshooting

Other VPS providers

What you create

A read-only API token (or a host list). Every vendor listing is paginated to the end with the vendor's maximum page size; requests time out after 30 seconds and rate limits (429, and 5xx) are retried with backoff.

Vultr API keys have no read-only scope; the key is stored encrypted and only used to list instances.

Pagination links returned by a vendor are only followed on the vendor's own API origin, so the token is never sent to another host.

What is collected

Server name, region and public IP. A host with a public IP gets a finding to restrict inbound access. CVE, secret and malware findings need the optional host sensor installed on each host.

Troubleshooting

DeepScan (opt-in disk scanning)

Every connection above is read-only and agentless. DeepScan is a separate, opt-in addition for AWS, Azure and Google Cloud: 10ETLabs snapshots VM disks, a short-lived scanner VM in your account reads the snapshot, and only findings metadata (package + CVE, secret type + path + fingerprint, malware signature, AI model file path/size/hash) comes back. Snapshots, scanner VMs and result files are deleted after every scan. It needs its own permission set, deployed from a separate template (templates/aws/deepscan.cfn.yaml / deepscan.tf, templates/azure/deepscan-setup.sh / deepscan.tf, templates/gcp/deepscan-setup.sh / deepscan.tf); the reader role is never changed. Turn it on under Cloud accounts → ⋯ → DeepScan or at the end of the connect wizard. Architecture, exact permissions, cost and troubleshooting are in docs/deepscan.md.

Host sensor

The host sensor is optional and runs on your VPS hosts to report package vulnerabilities, exposed secrets and malware. Save a VPS connection first, then copy the install script from the connection (the connection API key is shown once; rotate it to get a new one). Sensors report to the console's public URL.

Optional remediator (one-click fixes)

Nothing in this section is needed for scanning. A remediator is a second, separate identity you deploy on purpose so an Owner or Admin can approve one-click fixes. It never replaces the read-only identity, and one-click fixes are unavailable on a connection until its remediator is connected and verified. Set it up in Settings → Remediation (one card per AWS, Azure or Google Cloud connection).

No wildcard actions, no IAM or role-assignment rights, no object/blob/data access, and no resource deletion. Tests keep the templates identical to what the fix executors call (packages/cloud-aws/src/remediation/iam-actions.spec.ts, packages/cloud-azure/src/remediation.spec.ts, packages/cloud-gcp/src/remediation.spec.ts).

Verify (no write is attempted):

• AWS: the ARN is not the reader role, is in the connection's account, can be assumed with the remediator ExternalId, and STS reports that role.
• Azure: the client ID is not the reader app, the app signs in, and its effective permissions on the subscription include every action above (a warning if it holds more).
• Google Cloud: the key is not the reader service account, and testIamPermissions on the project returns every permission above.

On each card you choose which fixes the remediator may apply and whether two-person approval is required (the approver must not be the requester). To turn one-click fixes off, press Disconnect (credentials are wiped; history stays) and delete the stack / app / service account in your cloud.

For operators