Required permissions
The read-only and write permissions each MCM module needs in your cloud accounts, with ready-to-use policies to download.
Overview
MCM connects to your cloud accounts using credentials you provide directly when you onboard an account — there is no cross-account IAM role or trust relationship, with one exception: onboarding an AWS Organization can use a cross-account role in each member account (see AWS Organization onboarding). The permissions attached to that credential are exactly what determine which MCM modules can function for that account and what data they can see or change.
Each module below lists the permissions required, why MCM needs each one, and a ready-to-use policy you can copy straight into your cloud provider's console. Every permission block shows a provider tab — switch between them to see what applies to each. Only enable the modules you plan to use, and grant only the permissions listed for them — this follows the principle of least privilege.
| Provider / Integration | Credential Type |
|---|---|
| AWS | Access Key ID + Secret Access Key (IAM user) |
| AWS Organization | Access Key ID + Secret Access Key (IAM user) of the management account, plus a role to assume in each member account (or direct keys per member) |
| Azure | App Registration / Service Principal (Client ID, Client Secret, Tenant ID, Subscription ID) |
| GitHub | Personal Access Token with repository read access |
| Docker Hub | Access Token (read-only) |
| Docker | Client TLS certificate, for a self-hosted registry/host |
| GitLab | Access token with read access to your groups and projects |
| Bitbucket | API token or app password with read access to your workspaces and repositories |
| Linux hosts | SSH private key or password, for a user with sudo access (Ubuntu, Debian, RHEL, CentOS, SUSE, Amazon Linux, Oracle Linux, Rocky Linux, AlmaLinux) |
Read-only vs write access
Every permission on this page is split into read-only (describe, list and read — nothing in your account changes) and write (create, modify, delete, tag or install). Each table has separate columns for the two, and wherever a module needs both you get a separate read-only policy and write policy to download. Grant the read-only policy first, and add a write policy only for a feature you actually use.
| Module / feature | Read-only | Write — only needed if you… |
|---|---|---|
| AWS Organization onboarding | List the member accounts, assume the member role | Let MCM create the organization-wide audit trail (optional) |
| Discovery (AWS, Azure, GitHub, Docker Hub, Docker) | Everything | — none |
| Custom Tags (AWS, Azure) | Read tags and cost-allocation tags | Apply or remove tags from MCM |
| Cost & Usage Report — AWS existing bucket | s3:ListBucket, s3:GetObject on your bucket | — none (recommended) |
| Cost & Usage Report — AWS, MCM-created | Read the report files and exports | Let MCM create the bucket and Data Export, and remove old report files |
| Cost & Usage Report — Azure, Forecasting, Recommendations | Everything | — none |
| Governance (AWS, Azure, Linux hosts) | Every compliance check | Apply a remediation script on a Linux host (optional, on demand or automatic if you enable auto-remediation) |
| Audit Log (for Inventory Drift and Audit Log Security Scanning) — AWS existing bucket | s3:ListBucket, s3:GetObject on your bucket | — none (recommended) |
| Audit Log — AWS, MCM-created | Read the trail and log files | Let MCM create the CloudTrail trail and S3 bucket |
| Container and Source Code Security | Pull images / clone repositories | — none |
| Host Security and Observability | — | Install and manage the agents on the host (host-level access, no cloud permissions) |
| Orchestration (AWS, Azure) | Read the resources it manages | Create, update and delete the resources you provision |
Most modules only need read/describe/list access. Each module below calls out the specific cases where MCM performs a write action in your account. For FinOps and SecOps on AWS, if you already have a Cost & Usage Report or CloudTrail bucket, choose Use my existing S3 bucket (read-only) during onboarding: MCM then only needs read access to that bucket (see Cost & Usage Report and Audit Log). If you choose Use the data from another account, this account needs no bucket access at all: the account that owns the bucket reads it once.
Every JSON block is a ready-to-paste AWS IAM policy or Azure custom role definition — just replace the <your-aws-account-id> / <your-subscription-id> placeholder before creating it. In AWS, paste it into IAM → Policies → Create Policy → JSON. In Azure, paste it into Subscription → Access Control (IAM) → Add custom role → JSON — the Azure JSON blocks use the same format the Portal itself expects (properties → permissions → actions), not the flatter format shown by Azure PowerShell/CLI, so it uploads without a validation error. A Download link under each block saves it as a .json file if you'd rather upload a file than copy-paste.
AWS Organization onboarding
Supported for AWS only. Onboarding an AWS Organization needs a few permissions beyond a single AWS account, because MCM discovers the member (child) accounts and then reaches into each one you choose. The permissions below belong to the IAM user of the management (payer) account that you enter in the Credentials step.
| Read-only permissions | Write permissions | Why It's Needed |
|---|---|---|
organizations:DescribeOrganization, organizations:ListAccounts | — | Lists every account in the organization and identifies the management account, so you can choose which member accounts to onboard |
sts:AssumeRole on the member account's role (default OrganizationAccountAccessRole) | — | MCM signs in to each member account through AWS STS using the management-account credentials, so no separate access keys are needed per member. The role must trust the management account, and MCM asks for one-hour sessions, so its maximum session duration must be at least one hour |
| — | The MCM creates the bucket permissions from Cost & Usage Report (S3 bucket and AWS Data Export), on the management-account credentials | Only if you let MCM create the organization-wide Cost & Usage Report: MCM sets up one bucket and one export in the management (payer) account, once, and every onboarded member account uses it. No export is created per member |
| — | organizations:EnableAWSServiceAccess, organizations:ListAWSServiceAccessForOrganization, iam:CreateServiceLinkedRole | Only if you let MCM create the organization-wide audit trail: it turns on trusted access for CloudTrail so one trail captures every member account's events. The CloudTrail and S3 permissions it also needs are in Audit Log Security Scanning |
Members that use the organization Cost & Usage Report or audit trail (the default for members) need nothing extra, because MCM reads the management account's report and trail once for the whole organization — whether you point MCM at an existing report and trail or let it create them in the management account. See Cost & Usage Report and Audit Log Security Scanning.
For each member account, the Authentication & Access Mode step offers two ways in:
- Cross-Account IAM Role (default): MCM assumes the role described above. AWS creates
OrganizationAccountAccessRoleautomatically in accounts created from within the organization. To use another role, enter its ARN in Cross-Account Role ARN. - Direct IAM Credentials: give that member account its own Access Key ID and Secret Access Key with the module permissions on this page. Nothing else is needed.
Accounts you invited into the organization do not get OrganizationAccountAccessRole automatically: create the role there with the trust policy below, or use direct credentials. OrganizationAccountAccessRole has full administrator access by default; for least privilege, create your own role in each member account, attach the read-only policies from the module sections below and enter its ARN. If your role has a different name, change the role name in the sts:AssumeRole resource of the read-only policy.
Discovery
Discovery performs a read-only inventory scan across every connected account — AWS, Azure, GitHub, GitLab, Bitbucket, Docker Hub, Docker and Linux hosts. Switching on the Audit Log, Inventory Drift or Custom Tag features adds the permissions described in Audit Log and Custom Tags.
| Category | Read-only permissions | Why It's Needed |
|---|---|---|
| Account & Regions | sts:GetCallerIdentity, ec2:DescribeRegions | Confirms the credential belongs to your account during onboarding, and finds which AWS regions to scan |
| Compute | ec2:DescribeInstances, ec2:DescribeInstanceStatus, ec2:DescribeInstanceTypes, ec2:DescribeIamInstanceProfileAssociations, ec2:DescribeKeyPairs, ec2:DescribeImages | Lists your EC2 instances, their status and type, attached IAM instance profiles, key pairs, and AMIs for the resource inventory |
| Networking | ec2:DescribeVpcs, ec2:DescribeSubnets, ec2:DescribeRouteTables, ec2:DescribeInternetGateways, ec2:DescribeSecurityGroups, ec2:DescribeNetworkAcls | Maps your network topology — VPCs, subnets, routing, gateways, and security groups — into the inventory |
| Storage | ec2:DescribeVolumes, ec2:DescribeSnapshots, s3:ListAllMyBuckets, s3:GetBucketLocation, s3:GetBucketTagging, s3:GetBucketPolicy, s3:GetBucketPolicyStatus, s3:GetBucketAcl, s3:GetEncryptionConfiguration, s3:GetBucketVersioning, s3:GetBucketLogging, s3:GetBucketPublicAccessBlock, s3:GetBucketWebsite, s3:GetLifecycleConfiguration, s3:GetReplicationConfiguration, s3:GetBucketObjectLockConfiguration, s3:GetBucketNotification | Reads EBS volume/snapshot metadata, and every S3 bucket's configuration (encryption, versioning, policy, logging, replication) for the inventory |
| Database | rds:DescribeDBInstances, rds:ListTagsForResource | Lists RDS database instances and their tags |
| Containers | eks:ListClusters, eks:DescribeCluster, eks:ListTagsForResource | Lists EKS clusters and their tags |
| IAM | iam:ListPolicies, iam:GetPolicy, iam:GetPolicyVersion, iam:ListPolicyTags, iam:ListEntitiesForPolicy, iam:ListUsers, iam:GetUser, iam:ListAttachedUserPolicies, iam:ListUserPolicies, iam:GetUserPolicy, iam:ListGroupsForUser, iam:ListMFADevices, iam:GetLoginProfile, iam:ListUserTags | Reads IAM users and customer-managed policies so Discovery can include identity/access details in the inventory |
Custom Tags
Supported for both AWS and Azure.
| Read-only permissions | Write permissions | Why It's Needed |
|---|---|---|
ce:ListCostAllocationTags, organizations:DescribeOrganization | tag:TagResources, tag:UntagResources, ec2:CreateTags, ec2:DeleteTags, iam:TagRole, iam:TagPolicy, iam:TagUser, ce:UpdateCostAllocationTagsStatus | Lets you create custom tags and apply or remove them on resources (including tagging previously untagged resources), and activates them as AWS cost allocation tags so FinOps can break down costs by tag. The Organizations check confirms the account is the management/payer account before doing this org-wide. |
Tagging an IAM role, policy, or user through tag:TagResources also requires that IAM resource's own tag action — AWS treats the generic Resource Groups Tagging API as a proxy that still checks the underlying service's permission, so iam:TagRole / iam:TagPolicy / iam:TagUser are needed alongside tag:TagResources, not instead of it. The same applies to removing tags (iam:UntagRole / iam:UntagPolicy / iam:UntagUser) if you use that capability.
FinOps
Cost & Usage Report
MCM ingests your Cost & Usage Report (CUR) / Cost Details export on an ongoing basis. On AWS you can point MCM at a CUR export you already have in S3 (read-only access is enough), or let MCM create the bucket and export for you (create and read permissions).
MCM can read your Cost & Usage Report in two ways. If you already have a CUR export delivering to S3 — the common case — use your existing S3 bucket, which needs read-only access. Otherwise MCM can create the S3 bucket and Data Export for you, which needs create permissions as well. You pick the option when you onboard the account.
Choose Use my existing S3 bucket (read-only) for the Cost & Usage Report when you onboard the account and enter the bucket name (and, optionally, the S3 prefix) where your Cost & Usage Report files are delivered. MCM only reads the report files, so it needs just two S3 permissions — no write, delete or Data Exports access.
| Read-only permissions | Why It's Needed |
|---|---|
s3:ListBucket | Finds the report files for each billing month in your bucket |
s3:GetObject | Reads the Cost & Usage Report files (.csv.gz) so MCM can import your costs |
MCM never creates, changes or deletes your bucket, bucket policy, tags or Data Export, and does not remove files from it. Your bucket can have any name, so replace <your-cur-bucket> with it, and <your-prefix> with the S3 prefix you entered during onboarding (drop /<your-prefix> from the object resource if you did not set one).
- Bucket in another AWS account (for example a central billing account): an IAM policy alone is not enough — the bucket's own policy must also allow this IAM user to perform
s3:ListBucketands3:GetObject. - Encrypted with a customer-managed KMS key: also allow
kms:Decrypton that key. - AWS Organizations: the report lives in the management (payer) account and covers every member account, so MCM reads it once for all of them. Attach the read-only policy to the management account's credentials for an existing bucket, or the create-and-read policy if you let MCM create the bucket and export — it is created once in the management account, never per member. See AWS Organization onboarding.
Cost Forecasting
| Read-only permissions | Why It's Needed |
|---|---|
ce:GetCostForecast | Powers the Forecast dashboard by asking AWS Cost Explorer to project future spend |
Recommendations (Right-Sizing, Reserved Instances, Savings Plans)
| Read-only permissions | Why It's Needed |
|---|---|
compute-optimizer:GetEC2InstanceRecommendations, compute-optimizer:GetAutoScalingGroupRecommendations, compute-optimizer:GetEBSVolumeRecommendations, compute-optimizer:GetLambdaFunctionRecommendations, compute-optimizer:GetECSServiceRecommendations, compute-optimizer:GetRDSDatabaseRecommendations, ce:GetReservationPurchaseRecommendation, ce:GetSavingsPlansPurchaseRecommendation | Compute Optimizer actions drive Right-Sizing recommendations; the two Cost Explorer actions drive Reserved Instance and Savings Plan recommendations |
Tag Compliance reporting and Budget Management are evaluated from data already ingested above — neither needs any additional cloud provider permissions.
Governance
Governance runs read-only compliance checks (CIS Benchmark, GDPR, HIPAA, ISO, NIST, SOC 2) against your connected accounts and hosts. None of MCM's built-in policies modify or remediate anything automatically — every permission below only grants read access or, for Linux hosts, the ability to run a check script. The one write-capable path is the optional remediation script on Linux hosts, which runs when you trigger it, or automatically if you switch on Enable Auto-Remediation for that policy. Policies you write yourself can only check what the credential can read, so grant the read access that your own policies need as well.
| Category | Read-only permissions | Why It's Needed |
|---|---|---|
| Account, IAM & Access | iam:GetAccountPasswordPolicy, iam:GetAccountSummary, iam:GenerateCredentialReport, iam:GetCredentialReport, iam:ListUsers, iam:ListRoles, iam:ListPolicies, iam:ListGroups, iam:ListMFADevices, iam:ListUserPolicies, iam:ListRolePolicies, iam:GetRolePolicy, iam:ListAttachedGroupPolicies, iam:GetPolicyVersion, access-analyzer:ListAnalyzers | Evaluates password policy, MFA enrollment, credential age, and inline/attached IAM policies against framework controls |
| Logging & Monitoring | cloudtrail:DescribeTrails, cloudtrail:GetTrailStatus, config:DescribeConfigurationRecorders, config:DescribeConfigurationRecorderStatus, guardduty:ListDetectors, guardduty:GetDetector, logs:DescribeLogGroups | Confirms CloudTrail, AWS Config, and GuardDuty are enabled, as required by most compliance frameworks |
| Storage | s3:ListAllMyBuckets, s3:GetAccountPublicAccessBlock, s3:GetBucketLocation, s3:GetBucketAcl, s3:GetBucketPolicy, s3:GetBucketPolicyStatus, s3:GetBucketPublicAccessBlock, s3:GetEncryptionConfiguration, s3:GetBucketVersioning, s3:GetBucketLogging, s3:GetLifecycleConfiguration, s3:GetBucketObjectLockConfiguration, efs:DescribeFileSystems | Checks S3 bucket encryption, public access, versioning, and logging configuration, plus EFS file-system existence |
| Compute & Network | ec2:DescribeInstances, ec2:DescribeSecurityGroups, ec2:DescribeImages, ec2:DescribeVolumes, ec2:DescribeSnapshots, ec2:DescribeSnapshotAttribute, ec2:DescribeVpcs, ec2:DescribeFlowLogs, ec2:DescribeNetworkAcls, elasticloadbalancing:DescribeLoadBalancers, elasticloadbalancing:DescribeLoadBalancerAttributes, elasticloadbalancing:DescribeListeners | Checks security group exposure, EBS/snapshot public sharing, VPC flow log coverage, and load balancer logging |
| Database & Storage Services | rds:DescribeDBInstances, dynamodb:ListTables, dynamodb:DescribeTable, backup:ListBackupVaults | Checks RDS encryption/backup retention, DynamoDB table configuration, and backup vault existence |
| Encryption & Secrets | kms:ListKeys, kms:DescribeKey, kms:GetKeyRotationStatus, kms:GetKeyPolicy, secretsmanager:ListSecrets, ssm:DescribeParameters, acm:ListCertificates, acm:DescribeCertificate | Checks KMS key rotation and key policy exposure, Secrets Manager/SSM parameter existence, and ACM certificate expiry |
| Serverless & Messaging | lambda:ListFunctions, lambda:GetPolicy, sns:ListTopics, sns:GetTopicAttributes, sqs:ListQueues, sqs:GetQueueAttributes | Checks Lambda function resource policies for public exposure, and SNS/SQS topic/queue configuration |
| Containers & Other | ecr:DescribeRepositories, securityhub:GetFindings, guardduty:ListFindings, guardduty:GetFindings, shield:ListProtections, shield:DescribeSubscription | Folds in existing GuardDuty/Security Hub findings and Shield subscription status |
AWS labels iam:GenerateCredentialReport as a write action, but it only asks IAM to produce a credential report and changes nothing in your account, so it is grouped with the read-only permissions above.
The AWS managed policies SecurityAudit and ViewOnlyAccess, attached together, cover most of the table above. The notable gaps you'll need to add explicitly are: s3:GetAccountPublicAccessBlock, iam:GenerateCredentialReport, iam:GetCredentialReport, kms:GetKeyPolicy, lambda:GetPolicy, sns:GetTopicAttributes, sqs:GetQueueAttributes, and shield:DescribeSubscription.
SecOps
Audit Log (AWS and Azure)
The Audit Log (a Discovery feature that Inventory Drift and Audit Log Security Scanning build on) reads your cloud audit trail on an ongoing basis. For AWS, MCM reads your account's CloudTrail logs from S3 — from a bucket you already use, from a trail and bucket it creates for you, or from another onboarded account that already reads them.
Extra access for the bucket sources
- Your own (existing) bucket: the AWS user needs
s3:ListBucket,s3:GetBucketLocationands3:GetObjecton that bucket. If the bucket lives in another AWS account, its bucket policy must allow these actions for your account's user. MCM never writes to it. - Auto-delete of old logs (buckets MCM creates): additionally
s3:PutLifecycleConfigurationands3:GetLifecycleConfiguration. Without them MCM keeps working and simply skips auto-delete.
Azure Activity Log (Audit Log Scanning and Inventory Drift on Azure)
MCM reads your subscription's Activity Log through Azure's monitoring API. Nothing is created in your subscription. The built-in Reader role is enough (it includes Microsoft.Insights/eventtypes/values/read).
MCM can read your AWS audit log in two ways. If you already have a CloudTrail delivering to an S3 bucket — the common case — use your existing S3 bucket, which needs read-only access. Otherwise MCM can create a dedicated trail and bucket for you, which needs create permissions as well. You pick the option when you onboard the account.
Choose Use my existing S3 bucket (read-only) for CloudTrail when you onboard the account and enter the bucket your trail already delivers to (and the trail's S3 prefix, if it has one). MCM only reads the log files, so it needs two S3 permissions — it does not create, start, stop, update or delete your trail or bucket. Optionally, cloudtrail:DescribeTrails, cloudtrail:GetTrailStatus and cloudtrail:GetEventSelectors let MCM run health checks on the trail (is it logging, does it record write events); without them MCM shows a warning and keeps working.
| Read-only permissions | Why It's Needed |
|---|---|
s3:ListBucket | Confirms the bucket is reachable and finds the CloudTrail log files |
s3:GetObject | Reads the CloudTrail log files so MCM can analyze account activity for security findings |
cloudtrail:DescribeTrails, cloudtrail:GetTrailStatus, cloudtrail:GetEventSelectors (optional) | Health checks on the trail that delivers to your bucket |
Your trail must already be logging into that bucket. Replace <your-cloudtrail-bucket> with your bucket and <your-prefix> with the trail's S3 prefix (drop /<your-prefix> if the trail has none).
- Organization trail or a log-archive account: if the bucket lives in another AWS account, its bucket policy must also allow this IAM user to perform
s3:ListBucketands3:GetObject— otherwise MCM reports the bucket as unreachable. For an AWS Organization, attach the policy to the management account's credentials. - Encrypted with a customer-managed KMS key: also allow
kms:Decrypton that key.
Container Security (Docker Hub only)
| Read-only permissions | Why It's Needed |
|---|---|
| Read-only access permission (set when creating the token under Account Settings → Security → Access Tokens) | Lets MCM pull your images so Trivy can scan them for vulnerabilities. You can limit which image tags are scanned when you onboard the account |
Source Code Security (GitHub)
| Read-only permissions | Why It's Needed |
|---|---|
repo scope on a classic token, or Contents: Read-only on a fine-grained token | Lets MCM clone your repository so Trivy can scan it locally for vulnerabilities, secrets, and misconfigurations. No code-scanning, Dependabot, or secret-scanning API scopes are needed. A fine-grained token with Contents: Read-only keeps the credential strictly read-only; a classic token's repo scope also carries write access, which MCM never uses. |
Source Code Security (GitLab and Bitbucket)
GitLab and Bitbucket repositories are discovered and scanned the same way as GitHub: MCM lists your projects and branches, then clones the ones you chose so Trivy can scan them locally. Both need read access only.
| Platform | Read-only permissions | Why It's Needed |
|---|---|---|
| GitLab | An access token with read access to your groups, projects and repository contents (the read_api and read_repository scopes). For a self-hosted GitLab, also enter its base URL | Lists your groups, projects and branches for the inventory, and clones the repositories you chose to scan |
| Bitbucket | An API token or app password with read access to workspaces, projects and repository contents. For Bitbucket Data Center or Server, also enter its base URL | Lists your workspaces, projects, repositories and branches for the inventory, and clones the repositories you chose to scan |
Write permissions: none. Grant read-only scopes so the credential cannot change your code.
Host Security (Linux hosts)
Host scanning is not an IAM/RBAC model — it's direct OS-level access, and it is a write operation on the host itself (MCM installs and manages agents there). It needs no cloud API permissions.
| Write permissions (on the host) | Why It's Needed |
|---|---|
| Passwordless sudo | Lets MCM install and manage the Elastic Agent and the Falco/Zeek security tools on your host |
The host also needs to accept SSH connections on port 22 (or a custom port you configure), and needs outbound HTTPS access to the agent package repositories plus outbound access to MCM's monitoring endpoint on the configured registration port.
Orchestration
Orchestration provisions infrastructure through Terraform, on both AWS and Azure. Most workspaces are built from one of two curated pickers — Existing Stacks (21 ready-made templates) or the Blueprint Canvas (a drag-and-drop palette of 30 resource types) — each covering a specific, known set of AWS and Azure resource types, listed below with the exact permissions they need. A third option, uploading raw Terraform Files, accepts arbitrary HCL with no resource-type restriction — permissions for that path genuinely do scale with whatever you author and can't be listed here; grant the credential used by that workspace whatever create/read/update/delete permissions match the resource types in your uploaded configuration.
For the curated catalog, Terraform needs full lifecycle access — create, read, update, and delete — for each resource type, not just read access.
| Resource Type | Read-only permissions | Write permissions | Why It's Needed |
|---|---|---|---|
| VPC | ec2:DescribeVpcs, ec2:DescribeVpcAttribute | ec2:CreateVpc, ec2:ModifyVpcAttribute, ec2:DeleteVpc, ec2:CreateTags, ec2:DeleteTags | Full lifecycle for aws_vpc |
| Subnet | ec2:DescribeSubnets | ec2:CreateSubnet, ec2:ModifySubnetAttribute, ec2:DeleteSubnet, ec2:CreateTags, ec2:DeleteTags | Full lifecycle for aws_subnet |
| EC2 Instance | ec2:DescribeInstances, ec2:DescribeInstanceAttribute | ec2:RunInstances, ec2:ModifyInstanceAttribute, ec2:StopInstances, ec2:StartInstances, ec2:TerminateInstances, ec2:CreateTags, ec2:DeleteTags | Full lifecycle for aws_instance |
| S3 Bucket | s3:HeadBucket, s3:GetBucketPolicy, s3:GetBucketAcl, s3:GetBucketVersioning, s3:GetEncryptionConfiguration, s3:GetBucketPublicAccessBlock, s3:GetBucketOwnershipControls, s3:GetBucketTagging | s3:CreateBucket, s3:PutBucketAcl, s3:PutBucketVersioning, s3:PutEncryptionConfiguration, s3:PutBucketPublicAccessBlock, s3:PutBucketOwnershipControls, s3:PutBucketTagging, s3:DeleteBucket | Full lifecycle for aws_s3_bucket and its versioning/encryption/ownership/public-access sub-resources — this also covers the bucket-name availability check MCM runs while you're configuring the variable |
| Security Group | ec2:DescribeSecurityGroups | ec2:CreateSecurityGroup, ec2:AuthorizeSecurityGroupIngress, ec2:AuthorizeSecurityGroupEgress, ec2:RevokeSecurityGroupIngress, ec2:RevokeSecurityGroupEgress, ec2:DeleteSecurityGroup, ec2:CreateTags, ec2:DeleteTags | Full lifecycle for aws_security_group |
| Internet Gateway | ec2:DescribeInternetGateways | ec2:CreateInternetGateway, ec2:AttachInternetGateway, ec2:DetachInternetGateway, ec2:DeleteInternetGateway, ec2:CreateTags, ec2:DeleteTags | Full lifecycle for aws_internet_gateway |
| Route Table | ec2:DescribeRouteTables | ec2:CreateRouteTable, ec2:CreateRoute, ec2:ReplaceRoute, ec2:DeleteRoute, ec2:AssociateRouteTable, ec2:DisassociateRouteTable, ec2:DeleteRouteTable, ec2:CreateTags, ec2:DeleteTags | Full lifecycle for aws_route_table and aws_route_table_association |
| Network ACL | ec2:DescribeNetworkAcls | ec2:CreateNetworkAcl, ec2:CreateNetworkAclEntry, ec2:ReplaceNetworkAclEntry, ec2:DeleteNetworkAclEntry, ec2:DeleteNetworkAcl, ec2:CreateTags, ec2:DeleteTags | Full lifecycle for aws_network_acl |
| EBS Volume | ec2:DescribeVolumes | ec2:CreateVolume, ec2:ModifyVolume, ec2:DeleteVolume, ec2:CreateTags, ec2:DeleteTags | Full lifecycle for aws_ebs_volume |
| EBS Snapshot | ec2:DescribeSnapshots | ec2:CreateSnapshot, ec2:DeleteSnapshot, ec2:CreateTags, ec2:DeleteTags | Full lifecycle for aws_ebs_snapshot |
| Key Pair | ec2:DescribeKeyPairs | ec2:ImportKeyPair, ec2:CreateKeyPair, ec2:DeleteKeyPair, ec2:CreateTags, ec2:DeleteTags | Full lifecycle for aws_key_pair |
| IAM Role | iam:GetRole, iam:GetRolePolicy, iam:ListRolePolicies, iam:ListAttachedRolePolicies | iam:CreateRole, iam:UpdateRole, iam:UpdateAssumeRolePolicy, iam:PutRolePolicy, iam:DeleteRolePolicy, iam:AttachRolePolicy, iam:DetachRolePolicy, iam:DeleteRole, iam:TagRole, iam:UntagRole | Full lifecycle for aws_iam_role (Blueprint Canvas only) |
| Lambda Function | lambda:GetFunction, lambda:GetFunctionConfiguration, lambda:ListTags | lambda:CreateFunction, lambda:UpdateFunctionCode, lambda:UpdateFunctionConfiguration, lambda:DeleteFunction, lambda:TagResource, lambda:UntagResource, iam:PassRole | Full lifecycle for aws_lambda_function (Blueprint Canvas only); iam:PassRole lets Terraform attach the function's execution role |
| EKS Cluster | eks:DescribeCluster, eks:ListTagsForResource | eks:CreateCluster, eks:UpdateClusterConfig, eks:UpdateClusterVersion, eks:DeleteCluster, eks:TagResource, eks:UntagResource, iam:PassRole | Full lifecycle for aws_eks_cluster (Blueprint Canvas only); iam:PassRole lets Terraform attach the cluster's service role |
| RDS Instance | rds:DescribeDBInstances, rds:ListTagsForResource | rds:CreateDBInstance, rds:ModifyDBInstance, rds:DeleteDBInstance, rds:AddTagsToResource, rds:RemoveTagsFromResource | Full lifecycle for aws_db_instance (Blueprint Canvas only) |
Observability
Observability doesn't call any AWS or Azure cloud APIs — it connects directly over SSH to a Linux host (Ubuntu, Debian, RHEL, CentOS, SUSE, Amazon Linux, Oracle Linux, Rocky Linux or AlmaLinux), whether that host is a standalone server, an AWS EC2 instance, or an Azure VM. No AWS IAM or Azure RBAC permissions are required, so there's no policy JSON to provide. Its only write access is on the host itself, where it installs and runs the Elastic Agent.
| Write permissions (on the host) | Why It's Needed |
|---|---|
| No AWS IAM permissions — sudo/root access on the instance | Installs and runs an Elastic Agent on a Linux EC2 instance to collect its metrics and logs |
The host also needs outbound HTTPS access to the agent package repository, and network access to MCM's Elastic stack endpoint.