Cloud Connectors

    Pull cloud resources into your CMDB on a schedule, without giving Anzen long-lived credentials

    Anzen never receives long-lived cloud credentials

    Each provider uses the least-privilege mechanism that fits it. AWS connectors use a read-only IAM role in your account that trusts our platform; we assume it via STS for each discovery run. DigitalOcean connectors use a read-only Personal Access Token you generate, which is encrypted at rest and never shown back. Azure (when available) will use a service principal in your tenant. You can revoke our access at any time on your side - delete the AWS role, or revoke the DigitalOcean token - no support ticket required.

    What is a Cloud Connector?

    A cloud connector is a read-only integration between an Anzen entity and one cloud account. Once configured, Anzen lists the resources living in that account - EC2 instances on AWS today, and Droplets on DigitalOcean - and materialises them as Configuration Items under the chosen entity. The first run is the initial inventory; every subsequent run is a delta - new resources are added, existing ones are refreshed, removed ones stay until you delete them so the audit trail isn't broken.

    Providers

    Cloud Connectors is a plugin architecture - more providers will land over time. Available today:

    • Amazon Web Services (AWS) - generally available. Authenticates with an IAM role you create. Discovers EC2 instances at launch; RDS, S3, Lambda, and VPCs are tracked in the public roadmap.
    • DigitalOcean - generally available. Authenticates with a read-only Personal Access Token you paste into the wizard. Discovers Droplets (v1); reserved IPs, volumes, Kubernetes clusters, managed databases, and load balancers are future work.
    • Microsoft Azure - in development. Will use a service principal you create in your Azure tenant; the connector wizard already has the picker tile but it's marked "coming soon" until the provider ships.

    Setting Up an AWS Connector

    AWS uses an IAM role; DigitalOcean uses a read-only token (covered in its own section below). Setting up an AWS connector takes about five minutes if you have AWS console access:

    1. Open the wizard - go to Tools → Cloud Connectors and click Add connector. Pick AWS.
    2. Set up trust in your AWS account - paste your 12-digit AWS account ID, copy the CloudFormation template the wizard generates (it has your per-connector external-id pre-filled), and apply it in the AWS console. The template creates a single read-only IAM role named AnzenCustomerDiscoveryRole.
    3. Test the connection - click Test connection. Anzen runs the full two-hop AssumeRole chain end-to-end and echoes the assumed-role ARN it lands at, so you can confirm the right role is being assumed.
    4. Choose an entity and schedule - pick which entity discovered CIs land under, name the connector, and choose Daily (recommended) or Manual only.
    5. Review and create - the connector saves and runs immediately on demand if you click Run now on the detail page. Daily-scheduled connectors fire automatically each night.

    AWS Trust Model

    The AWS provider uses a deliberately layered authentication chain so that no single credential leak compromises customer data:

    • Caller IAM user - lives in the Anzen platform AWS account and has permission to assume only our internal discovery role. Used to bootstrap the chain. (This identity is being migrated to IAM Roles Anywhere with short-lived X.509 certs - no long-lived static credentials.)
    • Anzen discovery role - the intermediate hop. Has permission to assume only the customer role pattern (arn:aws:iam::*:role/AnzenCustomerDiscoveryRole) - no other powers. Compromise of this hop's session credentials cannot pivot into other Anzen-internal roles or platform-account resources.
    • Customer role - lives in your account, created by the CloudFormation template. Trusts our discovery role only when an sts:ExternalId condition matches the per-connector external-id we minted for you. Permissions baseline is the AWS-managed SecurityAudit + ViewOnlyAccess policies, which we plan to tighten to a custom least-privilege policy as our discovery surface stabilises.

    The external-id is the security primitive that makes the trust safe even if our platform-account ID ever leaks: AWS rejects any AssumeRole call to your role that doesn't carry the matching external-id you pasted into the CloudFormation parameter.

    Setting Up a DigitalOcean Connector

    DigitalOcean is deliberately simpler than AWS - there is no role, trust policy, or CloudFormation step. You generate a read-only token and paste it into the wizard:

    1. Create a read-only Personal Access Token - in the DigitalOcean control panel, go to API → Tokens and generate a new Personal Access Token (PAT). Give it read-only scope - Anzen only ever reads from your account, so write scope is never needed.
    2. Open the wizard - in Anzen, go to Tools → Cloud Connectors, click Add connector, and pick DigitalOcean.
    3. Paste the token - paste the PAT into the token field. Anzen encrypts it at rest and never displays it back; the connector only indicates that a token is stored. To rotate, paste a new token and the old one is replaced.
    4. Optionally filter by region - leave the region filter empty to discover Droplets across all regions, or set it to limit discovery to a single region (e.g. ams3).
    5. Choose an entity and schedule - pick which entity discovered Droplets land under, name the connector, and choose Daily (recommended) or Manual only, exactly as for AWS.

    Rotation is just a re-paste: generate a fresh read-only PAT in DigitalOcean, paste it into the connector, and revoke the old one in the DigitalOcean control panel. There is no stored token to read back, so a leaked Anzen export can never expose your DigitalOcean credentials.

    Residency note: DigitalOcean is US-headquartered, as are AWS and Microsoft Azure. This connector only inventories your own Droplets into your EU-hosted Anzen tenant - Anzen does not host your workloads on DigitalOcean. If you already run Droplets, it brings them into the same CMDB as the rest of your estate, and the residency choice for those workloads stays yours.

    What Gets Discovered

    Each cloud-discovered resource becomes a Configuration Item with the resource's cloud-native ID (e.g. an EC2 ARN) stored as external_id and the connector recorded as the source. CIs created this way show a small "Discovered by" attribution on the detail page. You can edit the entity assignment, add descriptions, or link the CI to applications and business processes; those edits survive subsequent discovery runs. Fields that the cloud provider populates - name, hostname, IP address, OS info - are refreshed every run so they stay in sync with reality.

    Scheduling and Manual Runs

    Connectors run on a daily cadence by default, as part of Anzen's nightly task runner. You can also click Run now on the connector's detail page at any time to trigger an out-of-band run; the result is recorded in the run history with an explicit "manual" trigger source. Set the schedule to Manual only if you'd rather control runs yourself - useful for cost-sensitive accounts or when you only need a snapshot. Each run records counts (discovered / created / updated / unchanged) and any per-resource errors, so partial failures are visible without having to dig through logs.

    Permissions

    Cloud Connectors use the standard Anzen RBAC system. The CloudConnector:read permission lets a user view the list, the connector detail page, and the run history. The CloudConnector:manage permission is required to add, edit, delete, or run a connector. Permissions are entity-scoped: a role granted on a specific entity governs only connectors targeting that entity (or any descendant). A connector cannot be moved across entities without the user holding manage on both the source and target.

    Disclaimer

    Cloud Connectors only read from your cloud accounts - on AWS using the read-only managed policies attached by the CloudFormation template, and on DigitalOcean using the read-only Personal Access Token you supply. Anzen / SCRTY B.V. accepts no liability for cloud API costs incurred by discovery runs (typically negligible), for misconfiguration of the customer-side IAM trust, or for the residency implications of inventorying a US-hosted provider's resources into your tenant. Always review the CloudFormation template before applying it, and scope your DigitalOcean token to read-only.