Skip to main content

AWS Least-Privilege Policies

Cloudaware’s AWS integration is designed to use read‑only access wherever possible. Use the patterns below to grant only the minimum rights required for each scenario.

Identity Model​

  • Prefer a cross‑account IAM role in each onboarded AWS account, assumed by Cloudaware using an External ID.
  • Optionally use a dedicated IAM user with access keys for specific accounts or legacy setups.
  • For AWS Organizations, use a combination of:
    • A role in the management account.
    • A StackSet‑deployed role in member accounts for automatic discovery and onboarding.

Baseline Discovery Access (Required)​

Cloudaware needs read‑only access to core AWS services (EC2, EBS, RDS, ELB, VPC, IAM metadata, and many others) to build the CMDB.

  • Use the Cloudaware‑provided CloudFormation template when adding an AWS account or organization:
    • The template creates a role with a trust policy that allows Cloudaware’s AWS account to assume it using sts:AssumeRole and an External ID.
    • It attaches Cloudaware’s collector policies that grant read‑only access across supported services.
  • You typically do not need to edit the trust policy when using the template.
  • Scope is per account; use AWS Organizations and StackSets to propagate the role to member accounts.

IAM User with Access Keys​

  • Create a dedicated IAM user for Cloudaware in the target account.
  • Attach Cloudaware’s collector policies (usually split into multiple policy documents to stay within AWS limits).
  • Avoid attaching broad policies like AdministratorAccess; the collector policies are designed to be read‑only.

For example policy documents, see base access policies in Cloudaware AWS IAM policies.

In both models, ensure that credentials or trust relationships are used only by Cloudaware and rotated according to your security policies.

Optional Extended Permissions by Feature​

Enable the following only if you plan to use the corresponding Cloudaware features.

Tagging from Cloudaware​

To allow Tag Analyzer and other workflows to manage tags on AWS resources:

  • Attach Cloudaware’s tagging policy (or an equivalent custom policy) to the IAM role or user.
  • Scope tagging permissions to the accounts and, where applicable, resource types you expect Cloudaware to update.

For AWS tagging permissions, see Cloudaware AWS IAM policies – Tagging.

To learn how to work with tags in Cloudaware, see Cloudaware Tag Analyzer.

CloudTrail and Configuration Data​

To enhance compliance and audit features:

  • Grant the Cloudaware IAM role or user read access to the S3 bucket that stores CloudTrail log files, including permissions:
    • s3:ListBucket on the bucket
    • s3:GetObject on the log object path/prefix

For an example policy, see Cloudaware AWS IAM policies – CloudTrail.

Billing​

For cost management and FinOps features:

  • Configure billing data exports (DBR/CUR/CUR 2.0) to an S3 bucket.
  • Grant the Cloudaware role or user permission to read the billing bucket (and, if applicable, KMS keys) using Cloudaware’s billing‑focused policies.

For an example policy, see Cloudaware AWS IAM policies – Billing.

EKS and Kubernetes‑Level Visibility​

To enrich EKS data with Kubernetes objects:

  • Ensure the Cloudaware IAM role used for the EKS account is allowed to access the cluster (via access entries or aws-auth ConfigMap mappings).
  • Apply the Kubernetes RBAC configuration described in the EKS Cluster Access for Cloudaware guide so that the mapped Kubernetes user has read access to cluster objects.

Backup, Monitoring, and Automation​

If you use Cloudaware to manage backup policies, schedules, or monitoring actions:

  • Attach the Cloudaware‑supplied optional policies that grant the necessary write actions (for example, on CloudWatch, Backups, or other services).
  • Keep these policies scoped narrowly to the accounts and resources involved in automation.

For example policies, see Backups, Unified Monitoring, and Instance Scheduler. For setup notes, see EC2/RDS Instance Scheduler.

Scoping Recommendations​

  • Use per‑account roles or users; avoid sharing credentials across unrelated accounts.
  • For organizations, use StackSets to roll out the same Cloudaware role to selected OUs instead of granting access to the entire organization by default.
  • Avoid attaching AdministratorAccess or similar broad policies to Cloudaware identities.
  • Review role and user permissions regularly and remove features you do not use to keep the privilege footprint small.