Be it either an IAM Role or IAM User at your end, Cavok Cloud asks for those permissions on your behalf:

{
  "PolicyDocument": {
    "Version": "2012-10-17",
    "Statement": [
      {
        "Sid": "Statements1",
        "Effect": "Allow",
        "Action": [
          "sts:AssumeRole",
          "iam:ListRolePolicies",
          "iam:ListAttachedRolePolicies",
          "iam:GetRolePolicy",
          "ec2:DescribeInstanceStatus",
          "ec2:DescribeInstances",
          "ec2:StartInstances",
          "ec2:StopInstances",
          "rds:DescribeDBClusters",
          "rds:DescribeDBInstances",
          "rds:StartDBCluster",
          "rds:StartDBInstance",
          "rds:StopDBCluster",
          "rds:StopDBInstance"
        ],
        "Resource": "*"
      },
      {
        "Sid": "Statements2",
        "Effect": "Allow",
        "Action": [
          "logs:CreateLogGroup",
          "logs:CreateLogStream",
          "logs:PutLogEvents",
          "logs:PutRetentionPolicy",
          "logs:TagResource"
        ],
        "Resource": "arn:aws:logs:*:*:log-group:/cavok/*"
      }
    ]
  }
}

Explanation of each subset of Permissions follows.

​
Required Permissions for Role

Skip this section if you’re using “Access Key” connection type for your Account

If you’re using “Assume Role” connection type, then 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.
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Statements3",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123115356005:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "CavokOrganizationId"
        }
      }
    }
  ]
}
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”

They are not used after an Account is marked as “Confirmed”.

​
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”

Cavok LogGroups are created with a default of 14 days retention. That can be changed afterwards on your end.

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

Was this page helpful?