Required Permissions
This section documents the permissions required by the administrator to perform various configuration tasks, and the permissions used by CloudCasa to provide various services.
Permissions required for AWS account linking
A cross-account role is used to grant the CloudCasa service permission to manage your RDS backups, manage snapshots of EKS EBS PVs, and perform backup and restore of EKS and associated services. For convenience, this is created using a CloudFormation stack and can be removed by removing the stack. The stack lets the user choose whether or not to include permissions for each function. A user with administrator permission is required in order to create the CloudFormation stack when initially linking your AWS account to your CloudCasa account, but the cross-account role that is used requires a much smaller set of permissions. The exact permissions used are the following:
For core functions:
iam:ListAccountAliases
ec2:DescribeRegions
iam:ListRoles
For enhanced EKS backup/restore (optional):
eks:CreateCluster
eks:DeleteCluster
eks:CreateNodegroup
eks:DeleteNodegroup
eks:DescribeCluster
eks:DescribeNodegroup
eks:ListClusters
eks:ListNodegroups
eks:TagResource
eks:ListAddons
eks:DescribeAddon
eks:DescribeAddonVersions
eks:CreateAddon
eks:DeleteAddon
eks:CreateAccessEntry
eks:AssociateAccessPolicy
eks:ListFargateProfiles
eks:DescribeFargateProfile
eks:CreateFargateProfile
eks:ListIdentityProviderConfigs
eks:DescribeIdentityProviderConfig
eks:AssociateIdentityProviderConfig
eks:DeleteAccessEntry
ec2:CreateVpc
ec2:CreateSubnet
ec2:DeleteVpc
ec2:DeleteSubnet
ec2:DescribeSubnets
ec2:DescribeKeyPairs
ec2:DescribeNetworkAcls
ec2:DescribeRouteTables
ec2:CreateInternetGateway
ec2:AttachInternetGateway
ec2:CreateRouteTable
ec2:CreateRoute
ec2:AssociateRouteTable
ec2:ModifySubnetAttribute
ec2:CreateSecurityGroup
ec2:AuthorizeSecurityGroupEgress
ec2:AuthorizeSecurityGroupIngress
ec2:DescribeLaunchTemplateVersions
ec2:CreateLaunchTemplate
ec2:RunInstances
ec2:DetachInternetGateway
ec2:DeleteInternetGateway
ec2:DisassociateRouteTable
ec2:DeleteRouteTable
ec2:DeleteSecurityGroup
ec2:CreateTags
ec2:DescribeLaunchTemplates
ec2:GetEbsEncryptionByDefault
ec2:GetEbsDefaultKmsKeyId
ec2:DeleteLaunchTemplate
iam:ListUsers
iam:PassRole
iam:GetRole
iam:ListAttachedRolePolicies
iam:CreateServiceLinkedRole
iam:CreateOpenIDConnectProvider
iam:UpdateAssumeRolePolicy
iam:GetRolePolicy
iam:GetPolicy
iam:ListEntitiesForPolicy
iam:ListPolicies
iam:ListRoleTags
iam:ListRolePolicies
autoscaling:DescribeLaunchConfigurations
autoscaling:DescribeAutoScalingGroups
autoscaling:CreateAutoScalingGroup
autoscaling:CreateLaunchConfiguration
elasticloadbalancing:DescribeLoadBalancers
kms:ListKeys
kms:DescribeKey
kms:ListAliases
kms:ListKeyPolicies
kms:GetKeyPolicy
For EBS volume snapshotting for EKS (optional):
ec2:DeleteSnapshot
ec2:CreateTags
ec2:DescribeVolumes
ec2:CreateSnapshot
ec2:DescribeSnapshots
ec2:CreateVolume
For RDS backup/restore (optional):
ec2:DescribeSecurityGroups
kms:CreateGrant
kms:DescribeKey
rds:CreateDBInstance
rds:DescribeDBClusters
rds:DescribeDBInstances
rds:ModifyDBInstance
rds:CreateDBSnapshot
rds:DescribeDBSnapshots
rds:DeleteDBSnapshot
rds:DescribeDBSubnetGroups
rds:CreateDBClusterSnapshot
rds:DescribeDBClusterSnapshots
rds:DescribeDBInstanceAutomatedBackups
rds:DeleteDBClusterSnapshot
rds:RestoreDBInstanceFromDBSnapshot
rds:RestoreDBClusterFromSnapshot
rds:DescribeDBParameterGroups
rds:DescribeDBClusterParameterGroups
rds:DescribeOptionGroups
rds:RestoreDBInstanceToPointInTime
rds:RestoreDBClusterToPointInTime
rds:CopyDBSnapshot
rds:CopyDBClusterSnapshot
rds:AddTagsToResource
Permissions required for Azure account linking
For Azure, CloudCasa uses Azure Lighthouse in order to gain the required limited access to customer’s subscription.
The user that deploys the template needs to have the Owner role or another role with the Microsoft.Authorization/roleAssignments/write
permission.
The permissions granted to CloudCasa depend on the features the user chooses to enable. The template always grants CloudCasa the following roles:
Azure Kubernetes Service Contributor Role - Required for inventory and restore of AKS clusters.
Azure Kubernetes Service Cluster Admin Role - Required in order to get access to a cluster. We use it for agent installation on discovered and restored clusters.
Managed Application Contributor Role - Required for inventory and restore of Azure Resource Groups.
Domain Services Contributor - Required for Azure VNet inventory and restore.
Optionally, the user can enable additional features:
Support restore of AKS with enabled Log Analytics
Support auto-discovery and backup of Load Balancers associated with AKS clusters
When the first feature is enabled, the template grants CloudCasa the Log Analytics Contributor role in order to create the Log Analytics Workspace. For the second feature, it grants CloudCasa the Network Contributor role.
Permissions required for GCP account linking
In GCP, we use Deployment Manager to create the resources for account linking, so the user needs to have access to create/update Deployment Manager Deployments. In the tutorial used to guide the process, we ask for two additional steps:
Enable required GCP APIs
Assign the “Owner” role to the “Google APIs Service Agent” principal
Both of these operations required additional permissions.
Summing up, the user needs to have the following permissions:
deploymentmanager.deployments.create
deploymentmanager.deployments.get
deploymentmanager.deployments.list
deploymentmanager.deployments.update
deploymentmanager.manifests.get
deploymentmanager.operations.get
deploymentmanager.resources.list
iam.roles.get
iam.roles.update
resourcemanager.projects.get
resourcemanager.projects.setIamPolicy
serviceusage.services.enable
serviceusage.services.list
Similar to our AKS support, we ask the user what features should be enabled. For example, load balancer support. The basic template creates a custom role with the following permissions:
container.clusters.create
container.clusters.update
container.clusters.delete
container.clusters.get
container.clusters.getCredentials
container.clusters.list
container.serviceAccounts.create
container.serviceAccounts.get
container.serviceAccounts.update
container.deployments.create
container.deployments.get
container.deployments.list
container.deployments.update
container.namespaces.create
container.namespaces.get
container.namespaces.update
container.clusterRoleBindings.create
container.clusterRoleBindings.get
container.clusterRoleBindings.update
container.clusterRoles.bind
container.clusterRoles.create
container.clusterRoles.escalate
container.operations.get
container.pods.list
container.events.list
container.customResourceDefinitions.create
container.customResourceDefinitions.get
container.thirdPartyObjects.create
container.thirdPartyObjects.get
container.daemonSets.create
container.secrets.create
compute.regions.get
compute.regions.list
compute.zones.get
compute.zones.list
compute.machineTypes.get
compute.machineTypes.list
compute.networks.list
compute.networks.get
compute.networks.create
compute.networks.updatePolicy
compute.networks.delete
compute.subnetworks.get
compute.subnetworks.create
compute.subnetworks.delete
compute.globalAddresses.list
compute.globalAddresses.create
compute.globalAddresses.delete
iam.serviceAccounts.actAs
There are 3 additional features that the user can choose to enable:
Load balancers support
Velero cluster restore with Workload Identity
Native Persistent Disk support
For each, we add additional permissions to the base permissions mentioned above.
For Load Balancers:
compute.networks.get
compute.networkEndpointGroups.get
compute.networkEndpointGroups.use
compute.urlMaps.list
compute.urlMaps.get
compute.urlMaps.create
compute.urlMaps.delete
compute.urlMaps.use
compute.backendServices.get
compute.backendServices.create
compute.backendServices.delete
compute.backendServices.use
compute.backendServices.update
compute.healthChecks.useReadOnly
compute.healthChecks.get
compute.healthChecks.create
compute.healthChecks.delete
compute.firewalls.list
compute.firewalls.get
compute.firewalls.create
compute.firewalls.delete
compute.targetHttpProxies.list
compute.targetHttpProxies.get
compute.targetHttpProxies.create
compute.targetHttpProxies.delete
compute.targetHttpProxies.use
compute.globalForwardingRules.list
compute.globalForwardingRules.get
compute.globalForwardingRules.create
compute.globalForwardingRules.delete
compute.globalAddresses.list
compute.globalAddresses.get
compute.globalAddresses.create
compute.globalAddresses.delete
compute.globalAddresses.use
compute.instanceGroups.get
compute.instances.get
For Velero restores with Workload Identity:
iam.serviceAccounts.list
iam.serviceAccounts.getIamPolicy
iam.serviceAccounts.setIamPolicy
Support for native persistent disks is a little different.
If the user enables this feature, we add one more permission to the CloudCasa role: compute.disks.list
.
Also, for this feature, we need to create another role with the following permissions:
compute.disks.get
compute.disks.create
compute.disks.createSnapshot
compute.snapshots.get
compute.snapshots.create
compute.snapshots.useReadOnly
compute.snapshots.delete
compute.zones.get
Permissions required for accessing Azure Blob Storage
The following permissions are required in order for CloudCasa to access Azure Blob Storage for backup storage. They must be granted to the service principal or storage account configured. See Storage for details on configuring user-supplied storage.
"Actions": [
"Microsoft.Storage/storageAccounts/*",
"Microsoft.Resources/subscriptions/resourceGroups/read",
"Microsoft.Resources/subscriptions/resourcegroups/resources/read",
"Microsoft.ContainerInstance/containerGroups/read",
"Microsoft.ContainerInstance/containerGroups/write",
"Microsoft.ContainerInstance/containerGroups/delete",
"Microsoft.ContainerInstance/containerGroups/start/action",
"Microsoft.ContainerInstance/containerGroups/stop/action"
]
"DataActions": [
"Microsoft.Storage/storageAccounts/blobServices/containers/blobs/*"
]
If you have questions about permissions required or used by CloudCasa, contact CloudCasa support.