Database Access AWS IAM Reference

The Teleport Database Service requires IAM permissions for various tasks depending on the database type and setup, such as discovering endpoints and metadata of the database servers, generating IAM authentication tokens, and assuming IAM roles.

You can generate IAM permissions with the teleport db configure aws print-iam command. For example, the following command would generate and print the IAM policies:

teleport db configure aws print-iam --types rds,redshift --role teleport-db-service-role

To learn more about IAM permissions for a specific type of database, refer to the related section below.

DynamoDB

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DynamoDBConnectAsIAMRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::aws-account-id:role/dynamodb-user-role"
            ]
        },
        {
            "Sid": "DynamoDBSessionTagging",
            "Effect": "Allow",
            "Action": "sts:TagSession",
            "Resource": [
                "*"
            ]
        }
    ]
}

The session tagging permissions are only required if you have configured tags under the aws.session_tags section of your Teleport database configuration.

IAM role as a DynamoDB database user

The Teleport Database Service assumes a user-specified IAM role when forwarding requests to DynamoDB on their behalf. DynamoDB-related IAM permissions must be attached to that IAM role.

Refer to Actions, resources, and condition keys for Amazon DynamoDB for more information about DynamoDB permissions.

To allow IAM Role teleport-db-service-role to assume IAM Role dynamodb-user-role, the following is generally required:

1. Configure Trust Relationships on dynamodb-user-role

teleport-db-service-role or its AWS account should be set as Principal in dynamodb-user-role's trust policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::external-aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "example-external-id"
        }
      }
    }
  ]
}

2. Configure Permissions Policies on teleport-db-service-role

teleport-db-service-role requires sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "arn:aws:iam::aws-account-id:role/dynamodb-user-role"
        }
    ]
}

Note that this policy can be omitted when teleport-db-service-role and dynamodb-user-role are in the same AWS account and teleport-db-service-role's full ARN is configured as Principal in dynamodb-user-role's trust policy.

3. Configure Permissions Boundary on teleport-db-service-role

If teleport-db-service-role does not have an attached Permissions boundary then you can skip this step. Otherwise, the boundary policy attached to teleport-db-service-role must include sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

ElastiCache for Redis

ElastiCache supports IAM authentication for Redis engine version 7.0 or above. This is the recommended way to configure Teleport access to ElastiCache.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ElastiCacheDescribeUsers",
            "Effect": "Allow",
            "Action": "elasticache:DescribeUsers",
            "Resource": "*"
        },
        {
            "Sid": "ElastiCacheConnect",
            "Effect": "Allow",
            "Action": "elasticache:Connect",
            "Resource": [
                "arn:aws:elasticache:us-east-2:aws-account-id:replicationgroup:replication-group",
                "arn:aws:elasticache:us-east-2:aws-account-id:user:*"
            ]
        }
    ]
}

See Authenticating with IAM for ElastiCache for more information.

ElastiCache managed users

If any ElastiCache users are tagged to be managed by Teleport, below are the IAM permissions required for managing the ElastiCache users:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ElastiCacheManageUsers",
            "Effect": "Allow",
            "Action": [
                "elasticache:DescribeUsers",
                "elasticache:ModifyUser"
            ],
            "Resource": "*"
        },
        {
            "Sid": "ElastiCacheManagePasswords",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:CreateSecret",
                "secretsmanager:DeleteSecret",
                "secretsmanager:DescribeSecret",
                "secretsmanager:GetSecretValue",
                "secretsmanager:PutSecretValue",
                "secretsmanager:TagResource",
                "secretsmanager:UpdateSecret"
            ],
            "Resource": [
                "arn:aws:secretsmanager:*:aws-account-id:secret:teleport/*"
            ]
        }
    ]
}

The default Secrets Manager key prefix that Teleport will use is "teleport/". If you have configured a custom key prefix in your Teleport database config, then you must update the IAM policy resource name teleport to match that custom prefix.

If you have configured a custom KMS key ID in your Teleport database config, then add the following to the IAM policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt",
                "kms:GenerateDataKey"
            ],
            "Resource": [
                "arn:aws:kms:*:aws-account-id:key/your-kms-id"
            ]
        }
    ]
}

Keyspaces

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "KeyspacesConnectAsIAMRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::aws-account-id:role/keyspaces-user-role"
            ]
        }
    ]
}

IAM role as a Keyspaces database user

The Teleport Database Service assumes a user-specified IAM role when forwarding requests to Keyspaces on their behalf. Keyspaces-related IAM permissions must be attached to that IAM role.

Refer to the Amazon Keyspaces identity-based policy examples for more information about the Keyspaces permissions that you can grant to an IAM role.

To allow IAM Role teleport-db-service-role to assume IAM Role keyspaces-user-role, the following is generally required:

1. Configure Trust Relationships on keyspaces-user-role

teleport-db-service-role or its AWS account should be set as Principal in keyspaces-user-role's trust policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::external-aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "example-external-id"
        }
      }
    }
  ]
}

2. Configure Permissions Policies on teleport-db-service-role

teleport-db-service-role requires sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "arn:aws:iam::aws-account-id:role/keyspaces-user-role"
        }
    ]
}

Note that this policy can be omitted when teleport-db-service-role and keyspaces-user-role are in the same AWS account and teleport-db-service-role's full ARN is configured as Principal in keyspaces-user-role's trust policy.

3. Configure Permissions Boundary on teleport-db-service-role

If teleport-db-service-role does not have an attached Permissions boundary then you can skip this step. Otherwise, the boundary policy attached to teleport-db-service-role must include sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

MemoryDB

MemoryDB supports IAM authentication for Redis engine version 7.0 or above. This is the recommended way to configure Teleport access to MemoryDB.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "MemoryDBDescribeUsers",
            "Effect": "Allow",
            "Action": "memorydb:DescribeUsers",
            "Resource": "*"
        },
        {
            "Sid": "MemoryDBConnect",
            "Effect": "Allow",
            "Action": "memorydb:Connect",
            "Resource": [
                "arn:aws:memorydb:us-east-2:aws-account-id:replicationgroup:replication-group",
                "arn:aws:memorydb:us-east-2:aws-account-id:user:*"
            ]
        }
    ]
}

See Authenticating with IAM for MemoryDB for more information.

MemoryDB managed users

If any MemoryDB users are tagged to be managed by Teleport, below are the IAM permissions required for managing the MemoryDB users:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "MemoryDBManageUsers",
            "Effect": "Allow",
            "Action": [
                "memorydb:DescribeUsers",
                "memorydb:ModifyUser"
            ],
            "Resource": "*"
        },
        {
            "Sid": "MemoryDBManagePasswords",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:CreateSecret",
                "secretsmanager:DeleteSecret",
                "secretsmanager:DescribeSecret",
                "secretsmanager:GetSecretValue",
                "secretsmanager:PutSecretValue",
                "secretsmanager:TagResource",
                "secretsmanager:UpdateSecret"
            ],
            "Resource": [
                "arn:aws:secretsmanager:*:aws-account-id:secret:teleport/*"
            ]
        }
    ]
}

The default Secrets Manager key prefix that Teleport will use is "teleport/". If you have configured a custom key prefix in your Teleport database config, then you must update the IAM policy resource name teleport to match that custom prefix.

If you have configured a custom KMS key ID in your Teleport database config, then add the following to the IAM policy:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "kms:Decrypt",
                "kms:GenerateDataKey"
            ],
            "Resource": [
                "arn:aws:kms:*:aws-account-id:key/your-kms-id"
            ]
        }
    ]
}

OpenSearch

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "OpenSearchCheckDomainURL",
            "Effect": "Allow",
            "Action": "es:DescribeDomains",
            "Resource": [
                "*"
            ]
        },
        {
            "Sid": "OpenSearchConnectAsIAMRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::aws-account-id:role/opensearch-user-role"
            ]
        }
    ]
}

IAM role as an OpenSearch database user

OpenSearch maps IAM roles to OpenSearch backend roles. The Teleport Database Service must be able to assume these "access" IAM roles to sign the OpenSearch API requests.

Refer to Fine-grained access control in Amazon OpenSearch Service for more information about the permissions you can configure for these roles.

To allow IAM Role teleport-db-service-role to assume IAM Role opensearch-user-role, the following is generally required:

1. Configure Trust Relationships on opensearch-user-role

teleport-db-service-role or its AWS account should be set as Principal in opensearch-user-role's trust policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::external-aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "example-external-id"
        }
      }
    }
  ]
}

2. Configure Permissions Policies on teleport-db-service-role

teleport-db-service-role requires sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "arn:aws:iam::aws-account-id:role/opensearch-user-role"
        }
    ]
}

Note that this policy can be omitted when teleport-db-service-role and opensearch-user-role are in the same AWS account and teleport-db-service-role's full ARN is configured as Principal in opensearch-user-role's trust policy.

3. Configure Permissions Boundary on teleport-db-service-role

If teleport-db-service-role does not have an attached Permissions boundary then you can skip this step. Otherwise, the boundary policy attached to teleport-db-service-role must include sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

RDS

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RDSAutoEnableIAMAuth",
            "Effect": "Allow",
            "Action": [
                "rds:ModifyDBCluster",
                "rds:ModifyDBInstance"
            ],
            "Resource": "*"
        },
        {
            "Sid": "RDSConnect",
            "Effect": "Allow",
            "Action": "rds-db:connect",
            "Resource": "*"
        },
        {
            "Sid": "RDSFetchMetadata",
            "Effect": "Allow",
            "Action": [
                "rds:DescribeDBClusters",
                "rds:DescribeDBInstances"
            ],
            "Resource": "*"
        }
    ]
}

The Teleport Database Service uses rds:ModifyDBInstance and rds:ModifyDBCluster to automatically enable IAM authentication on RDS instances and Aurora clusters, respectively. You can omit the RDSAutoEnableIAMAuth permissions if IAM authentication is already enabled on your databases.

The rds-db:connect permission is required to connect to databases. You can reduce the scope of the permission to only allow specific databases, regions, or users. The resource ARN has the following format:

arn:aws:rds-db:{Region}:{AccountID}:dbuser:{ResourceID}/{UserName}

Refer to Creating and using an IAM policy for IAM database access for more information about the rds-db:connect permission grant syntax.

Databases discovered by the Teleport Discovery Service should be registered with complete metadata, so you can also omit the RDSFetchMetadata permissions if all of your AWS databases are being auto-discovered.

RDS Proxy

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RDSProxyConnect",
            "Effect": "Allow",
            "Action": "rds-db:connect",
            "Resource": "*"
        },
        {
            "Sid": "RDSProxyFetchMetadata",
            "Effect": "Allow",
            "Action": [
                "rds:DescribeDBProxies",
                "rds:DescribeDBProxyEndpoints"
            ],
            "Resource": "*"
        }
    ]
}

The rds-db:connect permission is required to connect to databases. You can reduce the scope of the permission to only allow specific databases, regions, or users. The resource ARN has the following format:

arn:aws:rds-db:{Region}:{AccountID}:dbuser:{ResourceID}/{UserName}

Refer to Creating and using an IAM policy for IAM database access for more information about the rds-db:connect permission grant syntax.

Databases discovered by the Teleport Discovery Service should be registered with complete metadata, so you can also omit the RDSProxyFetchMetadata permissions if all of your AWS databases are being auto-discovered.

Redshift

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RedshiftConnectAsDBUser",
            "Effect": "Allow",
            "Action": "redshift:GetClusterCredentials",
            "Resource": "*"
        },
        {
            "Sid": "RedshiftConnectAsIAMRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::aws-account-id:role/redshift-user-role"
            ]
        },
        {
            "Sid": "RedshiftFetchMetadata",
            "Effect": "Allow",
            "Action": "redshift:DescribeClusters",
            "Resource": "*"
        }
    ]
}

You can reduce the scope of the RedshiftConnectAsDBUser statement by updating it to only allow specific users, databases, and database groups. The resource ARN you can specify has the following formats:

arn:aws:redshift:{Region}:{AccountID}:dbuser:{ClusterName}/{UserName}arn:aws:redshift:{Region}:{AccountID}:dbname:{ClusterName}/{DatabaseName}arn:aws:redshift:{Region}:{AccountID}:dbgroup:{ClusterName}/{DatabaseGroupName}

See Create an IAM role or user with permissions to call GetClusterCredentials for more information about the redshift:GetClusterCredentials permission grant syntax.

You can authenticate as an existing database user or as an IAM role that will be automatically mapped into the database. The corresponding IAM statement is only required for the method(s) you want to use. If an IAM role names the Database Service's identity as a trusted principal, and both identities are in the same AWS account, then the RedshiftConnectAsIAMRole statement can also be omitted.

Databases discovered by the Teleport Discovery Service should be registered with complete metadata, so you can also omit the RedshiftFetchMetadata permissions if all of your AWS databases are being auto-discovered.

IAM role as a Redshift database user

The following permissions policy should be attached to an IAM role that Teleport users can specify as a database user.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RedshiftConnectWithIAM",
            "Effect": "Allow",
            "Action": "redshift:GetClusterCredentialsWithIAM",
            "Resource": "*"
        }
    ]
}

An IAM role can connect as an automatically created database user with permissions mapped 1:1 from the identity's IAM permissions. Permissions in the database are granted with redshift-data:* statements attached to the IAM identity, for example redshift-data:GetStatementResult. Teleport users can connect as that role by specifying "role/{RoleName}" as a database user, e.g.

tsh db connect redshift-example-db --db-user=role/redshift-user-role

See Using identity-based policies for Amazon Redshift for more information about available Redshift IAM permissions that are mapped to the database user.

To allow IAM Role teleport-db-service-role to assume IAM Role redshift-user-role, the following is generally required:

1. Configure Trust Relationships on redshift-user-role

teleport-db-service-role or its AWS account should be set as Principal in redshift-user-role's trust policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::external-aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "example-external-id"
        }
      }
    }
  ]
}

2. Configure Permissions Policies on teleport-db-service-role

teleport-db-service-role requires sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "arn:aws:iam::aws-account-id:role/redshift-user-role"
        }
    ]
}

Note that this policy can be omitted when teleport-db-service-role and redshift-user-role are in the same AWS account and teleport-db-service-role's full ARN is configured as Principal in redshift-user-role's trust policy.

3. Configure Permissions Boundary on teleport-db-service-role

If teleport-db-service-role does not have an attached Permissions boundary then you can skip this step. Otherwise, the boundary policy attached to teleport-db-service-role must include sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

Redshift Serverless

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RedshiftServerlessConnectAsIAMRole",
            "Effect": "Allow",
            "Action": "sts:AssumeRole",
            "Resource": [
                "arn:aws:iam::aws-account-id:role/redshift-serverless-user-role"
            ]
        },
        {
            "Sid": "RedshiftServerlessFetchMetadata",
            "Effect": "Allow",
            "Action": [
                "redshift-serverless:GetEndpointAccess",
                "redshift-serverless:GetWorkgroup"
            ],
            "Resource": "*"
        }
    ]
}

Databases discovered by the Teleport Discovery Service should be registered with complete metadata, so you can also omit the RedshiftServerlessFetchMetadata permissions if all of your AWS databases are being auto-discovered.

Redshift Serverless maps IAM roles to database users. The Teleport Database Service must be able to assume these "access" IAM roles which are granted IAM permissions to generate IAM authentication tokens.

IAM role as a Redshift Serverless database user

The following permissions policy should be attached to an IAM role that Teleport users can specify as a database user.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "RedshiftServerlessConnect",
            "Effect": "Allow",
            "Action": "redshift-serverless:GetCredentials",
            "Resource": "arn:aws:redshift-serverless:us-east-2:aws-account-id:workgroup/workgroup-id"
        }
    ]
}

The resource ARN string has the following format:

arn:aws:redshift-serverless:{Region}:{AccountID}:workgroup/{WorkgroupID}

Teleport users can connect as the IAM role by specifying the role name as a database user, e.g.

tsh db connect redshift-serverless-example-db --db-user=redshift-serverless-user-role

See Identity and access management in Amazon Redshift Serverless for more information about configuring Redshift Serverless permissions.

To allow IAM Role teleport-db-service-role to assume IAM Role redshift-serverless-user-role, the following is generally required:

1. Configure Trust Relationships on redshift-serverless-user-role

teleport-db-service-role or its AWS account should be set as Principal in redshift-serverless-user-role's trust policy.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::aws-account-id:root"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::external-aws-account-id:role/teleport-db-service-role"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "example-external-id"
        }
      }
    }
  ]
}

2. Configure Permissions Policies on teleport-db-service-role

teleport-db-service-role requires sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "arn:aws:iam::aws-account-id:role/redshift-serverless-user-role"
        }
    ]
}

Note that this policy can be omitted when teleport-db-service-role and redshift-serverless-user-role are in the same AWS account and teleport-db-service-role's full ARN is configured as Principal in redshift-serverless-user-role's trust policy.

3. Configure Permissions Boundary on teleport-db-service-role

If teleport-db-service-role does not have an attached Permissions boundary then you can skip this step. Otherwise, the boundary policy attached to teleport-db-service-role must include sts:AssumeRole permissions, for example:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": "sts:AssumeRole",
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}