Permissions required for Managed kdb - Amazon FinSpace
Permissions FinSpace needs to resources in your account

Permissions required for Managed kdb

You must have certain IAM permissions to use Managed kdb. In addition to the finspace:*permissions, you might need additional permissions to use the resources in your AWS account. FinSpace uses these permissions on your behalf to configure resources in your account where it needs to function. Add these permissions by using the IAM policies to IAM roles that you use to interact with Managed kdb.

The following table shows a list of permissions and what they are needed for.

Permissions (IAM actions) Use for Used by
"logs:CreateLogDelivery" Creating and deleting CloudWatch logs Users who create or delete the clusters
"logs:GetLogDelivery"
"logs:UpdateLogDelivery"
"logs:DeleteLogDelivery"
"logs:ListLogDeliveries"
"logs:PutResourcePolicy"
"logs:DescribeResourcePolicies"
"logs:DescribeLogGroup"
"logs:CreateLogGroup"
"ec2:CreateVpcEndpoint" Managing kdb clusters Users who create or delete the clusters
"ec2:DeleteVpcEndpoints"
"ec2:DescribeSubnets"
"ec2:AcceptTransitGatewayVpcAttachment" Creating a connection between your Managed kdb environment and your transit gateway Administrators who configure the transit gateway environment using the UpdateKxEnvironmentNetwork API
"ec2:DescribeSubnets"
"ram:CreateResourceShare" Creating a resource share on the transit gateway Users who update kdb environment
“ram:GetResourceShareInvitiations” Accepting resource share on private certificate authority for cluster TLS connection Users who create kdb environment
"ram:AcceptResourceShareInvitation"
"iam:CreateServiceLinkedRole" Creating the FinSpace service-linked role (SLR) when creating a kdb environment Users who create kdb environment
"ec2:DescribeTags" Creating and describing tags on FinSpace managed VPC endpoints Users who create and delete clusters
"ec2:CreateTags"
"finspace:*" Performing actions to manage FinSpace resources Users that manage resources in FinSpace
"kms:CreateGrant" Encrypting any customer data at rest Users who create kdb environment
"kms:RetireGrant"
"ec2:DescribeTransitGateways" Checking if the transit gateway exists Users who configure the transit gateway environment using the UpdateKxEnvironmentNetwork API
"s3:GetObject" Controlling access for ingesting code and data into the service. Users who create clusters, update code on clusters, or create changesets. See the sections below for additional details.
"s3:GetObjectTagging"
"s3:GetObjectVersion"
"s3:ListBucket"

Permissions FinSpace needs to resources in your account

You will need to grant permission to FinSpace to access certain resources in your account. To do this, follow steps in the following sections.

Granting permission to your AWS KMS key to encrypt data and code stored in Managed kdb

You must grant the FinSpace service access by using the AWS KMS key policy to create Managed kdb changesets and load code onto a cluster. The following is an example of such a policy.

In the following example, replace each user input placeholder with your own values.

{
    "Version": "2012-10-17",
    "Id": "FinSpaceServiceAccess",
    "Statement": [{
            "Sid": "FinSpace Permissions",
            "Effect": "Allow",
            "Principal": {
                "Service": "finspace.amazonaws.com"
            },
            "Action": [
                "kms:Decrypt",
                "kms:DescribeKey",
                "kms:Encrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*"
            ],
            "Resource": "arn:aws:kms:us-east-1:555555555555:key/f935d84c-d365-4753-875Y-1c014ab4f61Z",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "555555555555"
                }
            }
        }

    ]
}

Granting permission to your Amazon S3 code bucket to load code onto your Managed kdb cluster

To load code onto your cluster you must first grant the FinSpace service access to the Amazon S3 bucket that stores the code you want to load. The following is an example of the policy that you can use to grant access to code location.

In the following example, replace each user input placeholder with your own values.

{
    "Version": "2012-10-17",
    "Id": "FinSpaceServiceAccess",
    "Statement": [{
            "Effect": "Allow",
            "Principal": {
                "Service": "finspace.amazonaws.com"
            },
            "Action": [
                "s3:GetObject",
                "s3:GetObjectTagging",
                "s3:GetObjectVersion"
            ],
            "Resource": "arn:aws:s3:::managed-kdb-code/*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "555555555555"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:finspace:us-east-1:555555555555:kxEnvironment/<EnvironmentID>/*"
                }
            }
        },
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "finspace.amazonaws.com"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::managed-kdb-code",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "555555555555"
                },
                  "ArnLike": {
                    "aws:SourceArn": "arn:aws:finspace:us-east-1:555555555555:kxEnvironment/<EnvironmentID>/*"
                }
            }
        }
    ]
}

After you grant the FinSpace service access to the S3 bucket , you must ensure that the IAM role that you use when you create a cluster or when you update the code on a cluster has permission to access the files on the Amazon S3 bucket. The following is an example of the policy that you can use to grant access to the role.

In the following example, replace each user input placeholder with your own values.

{
    "Version": "2012-10-17",
    "Id": "FinSpaceServiceAccess",
    "Statement": [{
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectTagging",
                "s3:GetObjectVersion"
            ],
            "Resource": "arn:aws:s3:::managed-kdb-code/*"
        },
        {
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::managed-kdb-code"
        }
    ]
}

When you set permissions on the role, you can control which Amazon S3 locations a user can access. You can also set Deny policies on this role to prevent access to resources. For example, you can use the Deny policy to prevent access to resources in another account.

Granting permission to your Amazon S3 data staging bucket to ingest data into Managed kdb

To ingest data from Amazon S3 into your database through a changeset, you must first grant FinSpace access to the S3 bucket that stores the data you want to import as Managed kdb changesets. The following is an example of such a policy.

In the following example, replace each user input placeholder with your own values.

In the following example, replace each user input placeholder with your own values.

{
    "Version": "2012-10-17",
    "Id": "FinSpaceServiceAccess",
    "Statement": [{
            "Effect": "Allow",
            "Principal": {
                "Service": "finspace.amazonaws.com"
            },
            "Action": [
                "s3:GetObject",
                "s3:GetObjectTagging",
                "s3:GetObjectVersion"
            ],
            "Resource": "arn:aws:s3:::managed-kdb-data/*",

            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "555555555555"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:finspace:us-east-1:555555555555:kxEnvironment/<EnvironmentID>/*"
                }
            }
        },
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "finspace.amazonaws.com"
            },
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::managed-kdb-data",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "555555555555"
                },
                "ArnLike": {
                    "aws:SourceArn": "arn:aws:finspace:us-east-1:555555555555:kxEnvironment/<EnvironmentID>/*"
                }
            }
        }
    ]
}

After you grant FinSpace access to the Amazon S3 bucket, you must ensure that the IAM role you use when you create a changeset has permission to access the files on the Amazon S3 bucket. The following is an example of such a policy.

In the following example, replace each user input placeholder with your own values.

{
    "Version": "2012-10-17",
    "Id": "FinSpaceServiceAccess",
    "Statement": [{
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:GetObjectTagging",
                "s3:GetObjectVersion"
            ],
            "Resource": "arn:aws:s3:::managed-kdb-data/*"
        },
        {
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::managed-kdb-data"
        }
    ]
}

When you set permissions on the role, you can control which Amazon S3 locations a user can access. You can also set Deny policies on this role to prevent access to resources. For example, you can use the Deny policy to prevent access to resources in another account.