Product documentation

1. Onboarding overview

Cloudryption onboarding is read-only, agent-free, and typically takes under one working day for a single cloud environment. The full onboarding guide is at onboarding.html.

The high-level steps are:

1. Create a read-only role or service account in your cloud environment.
2. Provide Cloudryption with the credentials (role ARN, service principal, or service account key).
3. Cloudryption runs its first discovery scan and builds an initial risk graph.
4. Review the initial findings, attack paths, and crown-jewel exposure in the platform.
5. Export an executive or technical report for stakeholder review.

2. AWS onboarding

Cloudryption connects to AWS using a cross-account IAM role with read-only permissions. No agents, no write access, no changes to your environment are required.

Step 1 — Create a cross-account IAM role

In your AWS account (or each member account), create an IAM role with the following trust policy, replacing CLOUDRYPTION_ACCOUNT_ID with the value provided during onboarding:

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

Step 2 — Attach the SecurityAudit managed policy

Attach the AWS-managed SecurityAudit policy (arn:aws:iam::aws:policy/SecurityAudit) to the role. This covers the majority of read-only discovery calls Cloudryption makes.

For complete coverage including GuardDuty findings, Security Hub, and AWS Config, also attach ReadOnlyAccess or the equivalent service-specific read policies.

Step 3 — Share the role ARN

Provide Cloudryption with the role ARN and the External ID set during setup. Cloudryption will validate access before running any scan.

Multi-account

For AWS Organizations, create the cross-account role in each member account you want scanned, using the same External ID. Cloudryption supports multi-account environments and will correlate findings and attack paths across accounts.

3. Azure onboarding

Cloudryption connects to Azure using a service principal (App Registration) with read-only Azure RBAC roles and Microsoft Graph API permissions.

Step 1 — Create an App Registration

In Azure Active Directory / Microsoft Entra ID, create a new App Registration. Generate a client secret (or certificate) and note the Tenant ID, Client ID, and Client Secret.

Step 2 — Assign Azure RBAC roles

At the subscription scope (or management group for multi-subscription), assign the following built-in roles to the service principal:

• Reader — read access to all Azure resource metadata
• Security Reader — read access to Microsoft Defender for Cloud findings and security scores

Step 3 — Grant Microsoft Graph API permissions

In the App Registration, add the following Application (not delegated) API permissions and grant admin consent:

• Directory.Read.All — user, group, service principal, and role discovery
• Application.Read.All — app registrations and service principal details
• AppRoleAssignment.Read.All — app role assignments across the tenant
• RoleManagement.Read.All — Entra ID role assignments and definitions

Step 4 — Share credentials

Provide Cloudryption with the Tenant ID, Client ID, and Client Secret. Credentials are stored encrypted and used only for discovery scans.

4. GCP onboarding

Cloudryption connects to GCP using a service account with read-only IAM roles bound at the organization or project level.

Step 1 — Create a service account

In each GCP project (or at organization level), create a dedicated service account for Cloudryption. Generate and download a JSON key, or use Workload Identity Federation if preferred.

Step 2 — Assign IAM roles

Grant the service account the following predefined roles:

• roles/viewer — read access to all project resources
• roles/iam.securityReviewer — IAM policy and service account visibility
• roles/cloudasset.viewer — Cloud Asset Inventory access for cross-resource graph building
• roles/securitycenter.viewer (optional) — Security Command Center findings, if enabled

Step 3 — Share credentials

Provide Cloudryption with the service account JSON key or the Workload Identity configuration. Keys are stored encrypted at rest.

5. Required permissions — summary

Cloudryption never requests write, modify, or delete permissions. All permissions are read-only.

6. Data collected

Full details are at security-architecture.html. In summary, Cloudryption collects:

• Cloud resource metadata: names, IDs, types, regions, tags, configuration attributes
• IAM and identity data: users, roles, service accounts, permissions, trust relationships, group memberships
• Network topology: VPCs, subnets, security groups, firewall rules, load balancers, DNS records, peering
• Compute: instance types, OS metadata, public/private IPs, attached storage, container images (names and tags only)
• Storage: bucket/container names, public access settings, encryption status, replication configuration
• Databases: engine type, endpoint, encryption status, access configuration — not data contents
• Security controls: findings from GuardDuty, Defender for Cloud, SCC, CloudTrail configuration, audit log status
• Kubernetes: workload names, namespaces, service accounts, RBAC bindings, pod security settings

7. Data not collected

Full details are at security-architecture.html. Cloudryption does not collect:

• Secret values, API keys, credentials, or certificate private keys
• Database contents, table data, or query results
• S3 / Blob / GCS object contents — only bucket metadata and access configuration
• Application logs, business transaction records, or user activity logs
• Employee PII, customer PII, or any personal data from your workloads
• Source code or build artifacts
• Container image layers or file system contents
• CloudWatch metrics, cost data, or billing information

8. Read-only mode

Cloudryption operates entirely in read-only mode. The platform:

• Does not install agents or modify cloud resources
• Does not create, update, or delete any infrastructure in your environment
• Does not execute remediation actions automatically — all remediation is advisory and requires explicit approval from the customer
• Uses only the cloud-provider APIs and the read-only roles described above
• Can be disconnected at any time by revoking the IAM role, service principal, or service account

Automated remediation via Jira, ServiceNow, or webhook integrations is available but must be explicitly configured and approved by the customer. It is disabled by default.

9. How attack paths are calculated

Cloudryption builds a directed graph from the collected cloud metadata. Nodes are cloud assets (identities, compute, storage, network, databases, security controls). Edges are relationships — trust, access, reachability, or exposure.

An attack path is a sequence of edges from an initial access point (a publicly reachable resource, an over-exposed identity, or a misconfigured service) to a sensitive target (a crown-jewel asset). Cloudryption uses graph traversal to enumerate all such paths and rank them by:

• Reachability — is the path currently traversable given observed network and IAM configuration?
• Exploitability — does each hop in the path have a known misconfiguration, excessive permission, or vulnerability?
• Impact — what is the business value of the target asset (crown-jewel weight)?
• Blast radius — how many crown-jewel assets can be reached from this path?

Paths are re-calculated after each scan. A remediation action is evaluated against the graph to predict how many attack paths it would collapse before it is recommended.

10. How crown jewels are inferred

Crown jewels are the assets that matter most to the business — the ones an attacker would most want to reach. Cloudryption infers crown-jewel candidates from observable signals in the cloud metadata:

• Tagging signals — resources tagged as production, sensitive, PII, confidential, or regulated
• Access concentration — resources that many identities or roles have elevated access to
• Data classification signals — databases, storage buckets, and data warehouses with encryption at rest, DLP policies, or audit logging enabled (indicating intentional protection)
• Business name signals — resource names containing keywords like finance, payment, customer, prod, backup, or vault
• Network exposure asymmetry — resources with strict inbound rules but wide outbound access (indicating protected stores)

Inferred crown jewels are presented to the customer for confirmation during onboarding. Customers can promote, demote, or manually define crown jewels via the platform.

11. Known limitations

• Single-region by default — the default scan targets one configured region per cloud account. Multi-region coverage requires additional configuration.
• API rate limits — Cloudryption respects cloud-provider API rate limits. Large accounts (10,000+ resources) may require longer scan windows or throttling configuration.
• Kubernetes requires network access — the Kubernetes connector requires network reachability to the cluster API server. Air-gapped clusters are not currently supported.
• Oracle Cloud is experimental — the Oracle connector is available but disabled by default. Enable with ORACLE_EXPERIMENTAL_ENABLED=true. Coverage is partial and not production-validated.
• Dynamic IAM policies — permission boundaries, SCPs, and attribute-based access control (ABAC) are collected but may not be fully reflected in attack path reachability in all edge cases.
• Crown-jewel inference is probabilistic — automated inference is a starting point. Human review and confirmation during onboarding produces more accurate results.
• No runtime/eBPF visibility — Cloudryption is control-plane focused. It does not observe running processes, network flows, or file system activity.
• SaaS identity providers — Okta, Entra ID, and Google Workspace identity connectors are on the roadmap but not yet available. Identity data is currently derived from cloud-provider IAM only.

12. Report samples

Cloudryption produces two report formats:

• Executive report — risk score, top exposures, decision summary, and residual risk outlook. Designed for CISOs, board presentations, and security committees.
• Technical report — finding detail, evidence chain, remediation steps, and validation checklist. Designed for security engineers and cloud architects.

13. Pilot process

Full details are at pilot.html. In summary:

1. Scope agreement — customer and Cloudryption agree on which cloud environments, accounts, and regions are in scope for the pilot.
2. Access setup — customer creates read-only access following the onboarding guide above (1–2 hours).
3. Initial scan — Cloudryption runs the first discovery scan and builds the initial risk graph (typically under 4 hours for environments with fewer than 5,000 resources).
4. Crown-jewel review — Cloudryption presents inferred crown jewels for customer confirmation.
5. Findings review — joint session to walk through top attack paths, exposures, and recommended remediations.
6. Pilot report — Cloudryption delivers an executive and technical report for the pilot scope.
7. Conversion — pilot fees may be credited toward an annual subscription if conversion occurs within 30 days of pilot completion.

Pilot packages start at €4,900. See pricing.html for current options.