A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://docs.aws.amazon.com/kms/latest/developerguide/cmks-in-iam-policies.html below:

Specifying KMS keys in IAM policy statements

Specifying KMS keys in IAM policy statements

You can use an IAM policy to allow a principal to use or manage KMS keys. KMS keys are specified in the Resource element of the policy statement.

When writing your policy statements, it's a best practice to specify only the KMS keys that the principal needs to use, rather than giving them access to all KMS keys.

For example, the following IAM policy statement allows the principal to call the DescribeKey, GenerateDataKey, Decrypt operations only on the KMS keys listed in the Resource element of the policy statement. Specifying KMS keys by key ARN, which is a best practice, ensures that the permissions are limited only to the specified KMS keys.

JSON
{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "kms:DescribeKey",
      "kms:GenerateDataKey",
      "kms:Decrypt"
    ],
    "Resource": [
     "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab",
     "arn:aws:kms:us-west-2:111122223333:key/01234abcd-12ab-34cd-56ef-1234567890ab"
    ]
  }
}

To apply the permission to all KMS keys in a particular trusted AWS account, you can use wildcard characters (*) in the Region and key ID positions. For example, the following policy statement allows the principal to call the specified operations on all KMS keys in two trusted example accounts.

JSON
{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "kms:DescribeKey",
      "kms:GenerateDataKey",
      "kms:GenerateDataKeyPair"
    ],
    "Resource": [
      "arn:aws:kms:*:111122223333:key/*",
      "arn:aws:kms:*:444455556666:key/*"
    ]
  }
}

You can also use a wildcard character ("*") alone in the Resource element. Because it allows access to all KMS keys the account has permission to use, it's recommended primarily for operations without a particular KMS key and for Deny statements. You can also use it in policy statements that allow only less sensitive read-only operations. To determine whether an AWS KMS operation involves a particular KMS key, look for the KMS key value in the Resources column of the table in AWS KMS permissions.

For example, the following policy statement uses a Deny effect to prohibit the principals from using the specified operations on any KMS key. It uses a wildcard character in the Resource element to represent all KMS keys.

JSON
{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Deny",
    "Action": [
      "kms:CreateKey",
      "kms:PutKeyPolicy",
      "kms:CreateGrant",
      "kms:ScheduleKeyDeletion"
    ],
    "Resource": "*"
  }
}

The following policy statement uses a wildcard character alone to represent all KMS keys. But it allows only less sensitive read-only operations and operations that don't apply to any particular KMS key.

JSON
{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": [
      "kms:CreateKey",
      "kms:ListKeys",
      "kms:ListAliases",
      "kms:ListResourceTags"
    ],
    "Resource": "*"
  }
}

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4