Cloud security posture
Connect cloud accounts and clusters read-only, and see every misconfiguration, how to fix it, and how you stand against your frameworks.
Cloud security posture reads the configuration of your cloud accounts and Kubernetes clusters and checks it against a library of rules: storage open to the internet, keys that never rotate, logging turned off, workloads running as root. Every failing check is a finding with the resource, the reason, when it started and the fix.
Connecting an account #
- Amazon Web Services — a read-only role in each account, created from the template on the Accounts page.
- Google Cloud — a read-only service account for each project.
- Microsoft Azure — the Reader role on each subscription.
- Kubernetes — a read-only agent in each cluster, installed with Helm or a plain manifest.
Open Security → Cloud Security → Accounts and choose Connect a cloud account. Sentinel only ever reads: it calls the provider's read and list operations under the role you grant, and never changes anything in your account. Connecting accounts needs the permission to manage integrations.
How scanning works #
- Each account is scanned on a schedule, every six hours by default.
- A read the role does not allow is reported as a gap on the Accounts page, with the exact permission to grant and the command that grants it. Rules that depend on that read are held back rather than reported as passing.
What you see #
- Overview — your posture score, how it is changing, and the findings by severity.
- Misconfigurations — failing rules, grouped by rule, with every affected resource. Each opens with the reasoning and the fix as your provider's CLI and as Terraform.
- Attack paths — chains of findings that together expose something sensitive, such as a public workload whose role can read a private bucket.
- Compliance — how each account stands against the frameworks below, control by control.
- Resources — everything the scans read, with the findings on each.
Frameworks #
Every rule maps to the controls it evidences, so the compliance view is built from the same checks rather than a separate questionnaire.
- CIS Foundations Benchmarks for AWS (v6.0.0), Google Cloud (v3.0.0) and Azure (v3.0.0).
- CIS benchmarks for Amazon EKS, Google Kubernetes Engine and Azure Kubernetes Service (v1.7.0), and for Kubernetes (v1.12.0).
- AWS Foundational Security Best Practices and the Kubernetes Pod Security Standards.
- SOC 2, PCI DSS v4.0, the HIPAA Security Rule and ISO/IEC 27001:2022.
Evidence, not certification
A compliance view shows how your configuration stands against a framework's technical controls. It is evidence for an audit, not a certification on its own.
Onward #
Who can connect accounts and act on findings is Identity and roles. Threats in your running services, rather than their configuration, are App and API protection and Security signals.