Using K10 with AWS EBS
The following permissions are needed by Kasten to operate on EBS, AWS EC2's underlying block storage solution
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CopySnapshot",
"ec2:CreateSnapshot",
"ec2:CreateTags",
"ec2:CreateVolume",
"ec2:DeleteTags",
"ec2:DeleteVolume",
"ec2:DescribeSnapshotAttribute",
"ec2:ModifySnapshotAttribute",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeRegions",
"ec2:DescribeSnapshots",
"ec2:DescribeTags",
"ec2:DescribeVolumeAttribute",
"ec2:DescribeVolumesModifications",
"ec2:DescribeVolumeStatus",
"ec2:DescribeVolumes"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "ec2:DeleteSnapshot",
"Resource": "*",
"Condition": {
"StringLike": {
"ec2:ResourceTag/name": "kasten__snapshot*"
}
}
},
{
"Effect": "Allow",
"Action": "ec2:DeleteSnapshot",
"Resource": "*",
"Condition": {
"StringLike": {
"ec2:ResourceTag/Name": "Kasten: Snapshot*"
}
}
}
]
}
The following additional permissions are required to use the EBS Direct API to get changed block data in a Block Mode Export.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ebs:ListSnapshotBlocks",
"ebs:ListChangedBlocks",
"ebs:GetSnapshotBlock"
],
"Resource": "arn:aws:ec2:*::snapshot/*"
}
]
}
Using K10 with AWS S3
While K10 can use AWS S3 to migrate applications between different clusters or even clouds, the access permissions should not be specified as a part of K10 install but instead later as a part of creating Location profiles. The credentials used for the profile should have the following permissions on the needed buckets.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:PutBucketPolicy",
"s3:ListBucket",
"s3:DeleteObject",
"s3:DeleteBucketPolicy",
"s3:GetBucketLocation",
"s3:GetBucketPolicy"
],
"Resource": [
"arn:aws:s3:::${BUCKET_NAME}",
"arn:aws:s3:::${BUCKET_NAME}/*"
]
}
]
}
Additional permissions are needed for creation and maintenance of immutable backups in K10.
s3:ListBucketVersionss3:GetObjectRetentions3:PutObjectRetentions3:GetBucketObjectLockConfigurations3:GetBucketVersionings3:GetObjectVersions3:DeleteObjectVersion
Using K10 with Amazon RDS
The credentials specified as a part of creating Location profiles should have the following permissions for K10 to perform Amazon RDS operations.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"rds:CreateDBInstance",
"rds:DeleteDBInstance",
"rds:DescribeDBInstances",
"rds:CreateDBSnapshot",
"rds:DeleteDBSnapshot",
"rds:DescribeDBSnapshots",
"rds:DescribeDBSnapshotAttributes",
"rds:CreateDBCluster",
"rds:DescribeDBClusters",
"rds:DeleteDBCluster",
"rds:CreateDBClusterSnapshot",
"rds:DeleteDBClusterSnapshot",
"rds:DescribeDBClusterSnapshots",
"rds:DescribeDBClusterSnapshotAttributes",
"rds:RestoreDBInstanceFromDBSnapshot",
"rds:RestoreDBClusterFromSnapshot"
],
"Resource": "*"
}
]
}
Using K10 with AWS EFS
K10 assumes that the user has successfully provisioned an EFS volume and is using the EFS CSI driver to mount the volume within Kubernetes. While K10 will transparently work with this setup, there are a couple of things to be aware of when using K10 to backup EFS that is different than EBS.
K10 creates its own vault to backup EFS
EFS volumes are created externally and today require manual cleanup when all references to it from Kubernetes are gone. This also means that when a restore happens, a manual cleanup of the old volumes will be needed.
Unlike EBS, EFS backups can be slow because of underlying AWS performance constraints with different data sets. Backup policy action frequencies should be set to accommodate this performance difference.
Finally, to operate on AWS EFS, K10 will need the following permissions to perform backup and restores.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"backup:CreateBackupVault",
"backup:DeleteRecoveryPoint",
"backup:DescribeBackupJob",
"backup:DescribeRecoveryPoint",
"backup:DescribeRestoreJob",
"backup:GetRecoveryPointRestoreMetadata",
"backup:ListRecoveryPointsByBackupVault",
"backup:ListRecoveryPointsByResource",
"backup:ListTags",
"backup:StartBackupJob",
"backup:StartRestoreJob",
"backup:TagResource",
"elasticfilesystem:CreateFileSystem",
"elasticfilesystem:CreateMountTarget",
"elasticfilesystem:CreateTags",
"elasticfilesystem:DeleteFileSystem",
"elasticfilesystem:DeleteMountTarget",
"elasticfilesystem:DescribeFileSystems",
"elasticfilesystem:DescribeMountTargets",
"elasticfilesystem:DescribeMountTargetSecurityGroups",
"elasticfilesystem:DescribeTags",
"elasticfilesystem:TagResource",
"sts:GetCallerIdentity"
],
"Resource": [
"*"
]
},
{
"Effect": "Allow",
"Action": [
"iam:PassRole"
],
"Resource": [
"arn:aws:iam::<accountID>:role/aws-service-role/elasticfilesystem.amazonaws.com/AWSServiceRoleForAmazonElasticFileSystem",
"arn:aws:iam::<accountID>:role/service-role/AWSBackupDefaultServiceRole"
]
}
]
}
Using K10 with AWS Secrets Manager
When enabling K10 DR using AWS Secrets Manager, it is required that an AWS Infrastructure Profile is created prior with credentials that have the adequate permissions.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::AccountId:role/EC2RoleToAccessSecrets"
},
"Action": "secretsmanager:GetSecretValue",
"Resource": "*"
}
]
}
More policy examples for secrets in AWS Secrets Manager are documented here.
Optional KMS Permissions
When operating on Encrypted EBS volumes, K10 will ensure snapshots and any new volumes created from those snapshots are encrypted with the same key.
If Customer Managed Keys (CMKs) are used to encrypt the EBS volumes, the following permissions should be granted for all KMS keys.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kms:GenerateDataKeyWithoutPlaintext",
"kms:DescribeKey",
"kms:ReEncryptTo",
"kms:ReEncryptFrom"
],
"Resource": "arn:aws:kms:::key/${KMS_KEY_ID}"
}
]
}