not_actions 与 IAM 策略中的显式拒绝和允许语句

not_actions vs explicit deny & allow statements in an IAM policy

政策 1:

data "aws_iam_policy_document" "kms_policy" {
  statement {
    sid = "AllowEKSKMSAccess"
    actions = [
      "kms:*"
    ]
    not_actions = [
      "kms:Delete*",
      "kms:ScheduleKeyDeletion",
      "kms:Revoke*",
      "kms:Disable*",
    ]
    resources = ["*"]
  }
}

政策 2:

data "aws_iam_policy_document" "kms_policy" {
  statement {
    sid = "AllowEKSKMSAccess"
    effect = "Allow"
    actions = [
      "kms:*"
    ]
    resources = ["*"]
  }

  statement {
    sid = "DenyEKSKMSDeletion"
    effect = "Deny"
    actions = [
      "kms:Delete*",
      "kms:ScheduleKeyDeletion",
      "kms:Revoke*",
      "kms:Disable*",
    ]
    resources = ["*"]
  }
}

我想在与托管 EKS 节点组关联的角色中阻止 4 项操作。

政策 1 还是政策 2 是首选政策?

在同一政策中有明确的 deny 声明(连同 allow 声明)是否更好?

Is policy 1 or policy 2 the preferred policy?

政策 2.

Is it better to have explicit deny statements (along with allow statements) in the same policy?

是 - 如果您想拒绝任何 IAM 操作,总是更喜欢显式拒绝策略。

An explicit deny in any policy overrides any allows.

只要原始拒绝策略不受更改,添加的任何试图允许不需要的操作的新策略都不会起作用

但是,当使用具有允许效果的 not_actions 时,为允许不需要的操作而添加的任何新策略实际上会逆转原始策略的效果,并且 将允许不需要的操作。没有明确的拒绝,就没有什么可以阻止其他人添加明确的允许(大多数情况下)。

始终首选第二个策略。

我只在我想拒绝很多东西时使用not_actions来使生成的IAM策略更小,因为我知道它保证是未来证明如果政策是 well-secured.