1. 15
  1.  

  2. 2

    Let me be the first to agree that AWS IAM is confusing.

    ReadOnlyAccess by itself is too permissive for most users. See [1] and [2]. You almost definitely do not want to give someone read-only access to all resources in an AWS account. There are other very useful managed policies, but before using them understand what they are and how they are updated.

    Instead of appending restrictions you should use another managed policy that you own to set a permission boundary [3]. So you can start off with ReadOnlyAccess, then scope it down to specific resources like s3:* etc.

    [1] https://alestic.com/2015/10/aws-iam-readonly-too-permissive/

    [2] https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html, “…the AWS managed policy called ReadOnlyAccess provides read-only access to all AWS services and resources. When AWS launches a new service, AWS updates the ReadOnlyAccess policy to add read-only permissions for the new service. The updated permissions are applied to all principal entities that the policy is attached to.”

    [3] https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html, “AWS supports permissions boundaries for IAM entities (users or roles). A permissions boundary is an advanced feature for using a managed policy to set the maximum permissions that an identity-based policy can grant to an IAM entity. An entity’s permissions boundary allows it to perform only the actions that are allowed by both its identity-based policies and its permissions boundaries. “

    1. 1

      Permission boundaries are cool, but I find them incredibly difficult to reason about =/

      1. 3

        Permission boundaries are cool, but I find them incredibly difficult to reason about =/

        Yes, IAM policies can be difficult to reason about. You can use [1] to analyze policies and check they aren’t too pernissive.

        Also in the blog post the author mentioned how ReadOnlyAccess gave you access to an SSM parameter. Yes. But let’s suppose you were using AWS Secrets Manager instead. SSM does not support resource-based policies, but Secrets Manager does [2]. A resource policy lets you put an IAM policy on the resource itself, e.g. a secret value [3], and that way no matter that an IAM role is authorized to do (hey you can read everything), if the resource’s policy disagrees you aren’t allowed to get access.

        Finally….AWS Systems Manager Parameters (SSM parameters) relies on AWS KMS to encrypt the secret values [4], and KMS keys support resource-based policies. Again, if some IAM role policy has access to all SSM parameters, but the resource-based policy on the KMS key does not grant it kms:Decrypt permission, then you will not be able to read that SSM parameter.

        Whew. ¯\_(ツ)_/¯

        [1] https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html

        [2] https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html

        [3] https://docs.aws.amazon.com/secretsmanager/latest/userguide/auth-and-access_resource-based-policies.html

        [4] https://docs.aws.amazon.com/kms/latest/developerguide/services-parameter-store.html

    2. 1

      There are many things wrong with AWS permissions. The article example is kind of weird. Generally speaking the new services does not play too well with the older services (config service with iam in this scenario).