Required Permissions for Role
Skip this section if you’re using “Access Key” connection type for your Account
sts:AssumeRole
is mandatory.
The IAM Role on your end will also need the following Trust Relationship Policy,
allowing one of our workload IAM Users to assume this role:
If you used our “Deploy on AWS” button at Account creation, that would have been done for you.
Principal > AWS > ARN
is a reference to our Workload AWS Account,
and CavokOrganizationId
is a reference to your Organization number with us.sts:ExternalId
is an AWS Best-Practice that enforces us to confirm a mutually known information
(but not a secret) in order to request temporary credentials at every SDK interaction.Checking Permissions
These permissions are only needed by our Account confirmation routine, to check if we can be sure our Resources won’t fail from lack of permissions:- “iam:ListRolePolicies”
- “iam:ListAttachedRolePolicies”
- “iam:GetRolePolicy”
Log Writing Permissions
If you allow us to register execution logs in your Account (at the Account Creation modal), we need those permissions:- “logs:CreateLogGroup”
- “logs:CreateLogStream”
- “logs:PutLogEvents”
- “logs:PutRetentionPolicy”
- “logs:TagResource”
We use a restriction: we only want to write on Cavok LogGroups:
"Resource": "arn:aws:logs:*:*:log-group:/cavok/*"
Operational Permissions
These can be removed if you don’t intend to use some of those Resources in your Account.EC2
We need these permissions:- “ec2:DescribeInstanceStatus”
- “ec2:DescribeInstances”
- “ec2:StartInstances”
- “ec2:StopInstances”
RDS
We need these permissions:- “rds:DescribeDBClusters”
- “rds:DescribeDBInstances”
- “rds:StartDBCluster”
- “rds:StartDBInstance”
- “rds:StopDBCluster”
- “rds:StopDBInstance”
Aurora databases are “clusters” and need those permissions