Connect Cloud Accounts

Cloud integrations belong to the workspace where you create them. They provide the live infrastructure context used in that workspace by:

Cloud compliance scans
Cloud monitor findings
Cloud resource inventory and import
DevOps Agent sessions that need cloud-side context

Choose the workspace you want to configure, open Integrations, and select Cloud.

Connection Methods

Provider	Connection methods	Notes
AWS	Access key credentials	Use a dedicated IAM identity
Azure	Quick Connect or manual service principal	Both methods are supported
GCP	Keyless impersonation or service account key	Keyless impersonation avoids a long-lived key
Kubernetes	Kubeconfig	Static token or inline client certificate
OCI	API key credentials	Uses tenancy, user, fingerprint, and private key
Exoscale	IAM API key and secret	Use a restricted inventory key
OpenShift	Kubeconfig	Kubernetes access plus OpenShift APIs

Principle: Read First, Write Never

For onboarding and scanning, Cloudgeni is designed around read access to your cloud estate. The product reads live state, runs scans, and uses that context to open repository changes later. It is not supposed to apply infrastructure changes directly in your cloud account.

AWS

Use a dedicated IAM user with read-only access:

aws iam create-user --user-name cloudgeni-readonly

aws iam attach-user-policy \
  --user-name cloudgeni-readonly \
  --policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

aws iam create-access-key --user-name cloudgeni-readonly

Take the AccessKeyId and SecretAccessKey into the AWS integration form.

Azure

Choose Quick Connect to create the service principal and required role assignments through an Azure authorization flow. Choose Manual to enter credentials for a service principal managed by your organization. Both methods are supported. Quick Connect creates a subscription-scoped service principal with roles for resource inventory, security posture, Log Analytics access, Terraform state discovery, and Azure Cost Management summaries. The Cost & Billing views need Cost Management Reader; plain Reader access can discover resources while still returning no actual billing rows. For Manual setup, create a subscription-scoped service principal with this role set:

export SCOPE="/subscriptions/$AZURE_SUBSCRIPTION_ID"

SP_JSON=$(az ad sp create-for-rbac \
  --name cloudgeni-reader \
  --role Reader \
  --scopes "$SCOPE" \
  --output json)

# Requires jq (https://jqlang.org/download/) in addition to az CLI.
APP_ID=$(echo "$SP_JSON" | jq -r .appId)
CLIENT_SECRET=$(echo "$SP_JSON" | jq -r .password)
TENANT_ID=$(echo "$SP_JSON" | jq -r .tenant)

SP_OBJECT_ID=$(az ad sp show --id "$APP_ID" --query id --output tsv)

for ROLE in \
  "Cost Management Reader" \
  "Security Reader" \
  "Log Analytics Reader" \
  "Storage Account Key Operator Service Role"
do
  az role assignment create \
    --assignee-object-id "$SP_OBJECT_ID" \
    --assignee-principal-type ServicePrincipal \
    --role "$ROLE" \
    --scope "$SCOPE"
done

Capture the full create-for-rbac output before extracting fields: the client secret (password) is returned exactly once and cannot be retrieved later. The manual credential form needs APP_ID (client ID), CLIENT_SECRET, and TENANT_ID. Passing --assignee-object-id with --assignee-principal-type ServicePrincipal avoids the “principal not found” failures that can occur when a role assignment races Entra ID replication right after the principal is created. Enter the subscription ID, tenant ID, client ID, and client secret in the Manual form. See Azure Setup for the complete flow and verification steps.

GCP

Cloudgeni supports two modes:

Keyless impersonation
Service account key upload

Keyless impersonation is the better default because Cloudgeni requests short-lived tokens on demand instead of storing a reusable key. The exact setup flow in the app uses this platform service account: cloudgeni-platform-sa@cloudgeni-production.iam.gserviceaccount.com Minimal impersonation example:

export PROJECT_ID="your-project-id"
export CLOUDGENI_SA="cloudgeni-access@$PROJECT_ID.iam.gserviceaccount.com"

gcloud iam service-accounts create cloudgeni-access \
  --display-name="CloudGeni Access" \
  --project=$PROJECT_ID

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:$CLOUDGENI_SA" \
  --role="roles/viewer"

gcloud projects add-iam-policy-binding $PROJECT_ID \
  --member="serviceAccount:$CLOUDGENI_SA" \
  --role="roles/serviceusage.serviceUsageConsumer"

gcloud iam service-accounts add-iam-policy-binding $CLOUDGENI_SA \
  --member="serviceAccount:cloudgeni-platform-sa@cloudgeni-production.iam.gserviceaccount.com" \
  --role="roles/iam.serviceAccountTokenCreator" \
  --project=$PROJECT_ID

Kubernetes

Connect one cluster per integration with a read-only kubeconfig. Cloudgeni accepts static bearer tokens or inline client certificate/key data; kubeconfigs that execute a local cloud CLI plugin are not supported by the hosted scanner. The setup form can generate a least-privilege service-account manifest and compatible kubeconfig commands. See Kubernetes Setup for the credential and reachability requirements.

OCI

You need a dedicated user, an API key pair, and a policy that grants read access to the tenancy or compartment you want Cloudgeni to inspect.

# Example policy statements to place in an OCI policy
Allow group CloudGeniReaders to inspect compartments in tenancy
Allow group CloudGeniReaders to read all-resources in tenancy

Use a dedicated user in that group, upload the public API key in OCI, and then enter the user OCID, tenancy OCID, fingerprint, and private key in the Cloudgeni form.

Exoscale

Create a restricted Exoscale IAM API key with read access to resource inventory. Enter the API key, secret, and default zone in the integration form. Exoscale inventory is supported; no compliance framework is currently mapped to Exoscale findings. See Exoscale Setup.

OpenShift

OpenShift uses the same static kubeconfig requirements as Kubernetes and additionally inventories OpenShift resources such as projects, routes, security context constraints, and cluster versions. See OpenShift Setup.

After The Account Is Connected

The next useful actions are:

Run Cloud Compliance for framework-based posture scans
Review Cloud Monitors for native provider findings
Open Cloud Resource Import if you want to recover IaC from live resources

What To Check If Setup Fails

Integration is present but not useful: verify the account really has enough read scope for the resources you expect
No findings or inventory appear: run a sync or scan from the integration page after the connection becomes active
Agent work lacks cloud context: make sure you selected the cloud account when launching the session, not just connected it earlier

Getting Started

Trust

Features

Integrations

CLI

Compliance

Troubleshooting

Support

Connect Cloud Accounts

Connect Cloud Accounts

Connection Methods

Principle: Read First, Write Never

AWS

Azure

GCP

Kubernetes

OCI

Exoscale

OpenShift

After The Account Is Connected

What To Check If Setup Fails

​Connect Cloud Accounts

​Connection Methods

​Principle: Read First, Write Never

​AWS

​Azure

​GCP

​Kubernetes

​OCI

​Exoscale

​OpenShift

​After The Account Is Connected

​What To Check If Setup Fails

Connect Cloud Accounts

Connection Methods

Principle: Read First, Write Never

AWS

Azure

GCP

Kubernetes

OCI

Exoscale

OpenShift

After The Account Is Connected

What To Check If Setup Fails