CSPM Prerequisites

Read-only access model, network reachability, identity, supported providers, and SaaS vs hybrid/on-prem assumptions to prepare before connecting a cloud account to Sec1 CSPM.

This page lists everything you need before connecting a cloud account to Sec1 CSPM. The next page, Required Permissions, has the exact per-cloud role lists; this page covers the access model, reachability, identity, and deployment assumptions that apply across all clouds.

All cloud access is read-only. Sec1 CSPM is agentless — a per-account scanning identity reads your cloud control plane and (optionally) cluster state. Sec1 never creates, modifies, or deletes your resources.

---

1. Supported providers

Provider	Cloud posture	Kubernetes
Google Cloud (GCP)	Supported	GKE
Microsoft Azure	Supported	AKS
AWS	Account / Organization	EKS

AWS uses the read-only roles documented in Required Permissions. Grant them to connect AWS accounts and EKS clusters.

---

2. The read-only access model

Sec1 needs one scanning identity per cloud account, granted read-only roles:

• GCP — a service account (key, or Workload Identity Federation) with viewer / security-reviewer roles.

• Azure — a service principal with Reader / Security Reader plus admin-consented Microsoft Graph read permissions.

• AWS — an IAM role Sec1 assumes cross-account (with an external ID), attaching read-only managed policies.

For Kubernetes, the same identity is additionally granted cluster read access plus a one-time, in-cluster read-only RBAC binding (for example, a ClusterRole that can read Secret metadata only — names and types, never secret values).

The complete role lists are on the Required Permissions page.

Single-account or organization-scope. You can onboard one project/subscription at a time, or at organization scope to discover and onboard many at once. The only extra prerequisite for org-scope is granting the same read-only roles at a higher node — a GCP organization/folder or an Azure management group — plus a listing permission so Sec1 can enumerate the children. Child projects/subscriptions then inherit the roles. See Organization-scope permissions and Onboard at organization scope.

---

3. Network & reachability

Requirement	Why it's needed	Applies to
Cloud management APIs reachable from the scanner	All posture, compliance, and inventory reads	All connectors
Cluster API server (control plane) reachable	Kubernetes misconfiguration scanning	GKE / AKS / EKS
Outbound HTTPS from the scanner to the Sec1 platform	Connector operation, license and threat-intel/CVE feed sync	All
Egress (or a configured proxy) for threat-intel / CVE feeds	Risk prioritisation enrichment	All (offline option below)

Private control planes: if a GKE/AKS/EKS cluster's API server is not publicly reachable, you must either authorise the scanner's egress on the cluster's control-plane authorized networks / authorized IP ranges (or, on GKE, use Connect Gateway), or run Sec1 inside your network in a hybrid deployment so it reaches the private endpoint directly. The exact reachability requirement is stated generically per cloud on the Required Permissions page.

---

4. Identity & SSO

• Access to the Sec1 console with permission to add cloud accounts (an account/admin or security role).

• Team-based access — connectors and their findings are scoped to the team that owns them, so each team sees only its own cloud accounts.

• SSO — if your organisation uses single sign-on, log in through your configured identity provider before onboarding.

• A scoped Sec1 API token if you intend to drive scans or pull findings via the REST API (created in the console; team-scoped and least-privilege).

---

5. SaaS vs hybrid / on-prem

Pick one model per environment and keep it consistent. The read-only roles are identical in both models — only reachability and where data resides differ.

	SaaS (Sec1-hosted)	Hybrid / on-prem (self-managed)
Where the scanner runs	On the Sec1 platform	Inside your network / VPC
Cloud reachability	Your cloud APIs and cluster control planes must be reachable from the Sec1 platform's egress	Scanner reaches cloud APIs and private control planes from inside your perimeter
Private control planes	Require authorized-network / allow-list entries (or Connect Gateway on GKE)	Reachable directly; no public exposure needed
Self-managed / on-prem Kubernetes	Control plane must be reachable from the platform	Scanner runs alongside the cluster
Threat-intel / CVE feeds	Synced by the platform	Synced through your proxy, or imported on a cadence for air-gapped environments
Data residency	Resource configuration metadata and finding evidence stored in your Sec1 tenant	Stays within your boundary; only license validation and (optional) feed sync egress

Air-gapped / proxy feeds (hybrid): if outbound egress to public feeds is not permitted, configure the Sec1 feed mirror so threat-intel, CVE, and compliance-framework content can be synced through your proxy or imported offline on a schedule. Posture scanning itself needs no internet — only the enrichment feeds do.

---

6. Pre-onboarding checklist

Before you start onboarding, confirm you have:

• Chosen the SaaS or hybrid/on-prem model for this environment.

• The read-only scanning identity created per cloud (see Required Permissions).

• Network reachability to the cloud APIs (and to any cluster control planes you want to scan).

• Console access on the team that will own the connector.