SummerFest 2023 - Imagine Dragons - Milwaukee, WI

Defining the Sensitive IAM Actions

Way back when I was working at Turner and deploying security audit roles, there were concerns over the level of access the ReadOnlyAccess policy would provide. We would have access to data that we were legally obligated to protect, but due to licensing and competition reasons, we could not be allowed to access. At the time, the specific division I was working with only stored this data in S3 and DynamoDB, so crafting a workaround that met everyone’s needs was reasonably straightforward.

Fast forward five years. AWS has gotten more complex, there are more services, and there still is no clear delineation between the access needed to audit an environment vs the access to the data in the environment.

[ tl;dr - here is a link to the repo ]

Mike Julian (the socially well adjusted half of the Duckbill Group) recently reached out to understand how they could improve the roles the ask of their clients. The need to do a security audit and the work they do around cost optimization & architecture are generally similar. Both need to know how the account is configured, but not necessarily the data that is in the account.

The common wisdom is to avoid the use of the clearly over permissive ReadOnlyAccess managed policy. But the alternatives, ViewOnlyAccess or SecurityAudit, aren’t adequate. There are 110 services in ReadOnlyAccess that are not in the ViewOnly/SecurityAudit managed policy.

The above-linked report from Rodrigo Montoro summarized the problem:

We reiterate that the problem does not lie in the ReadOnlyAccess policy but in the lack of comprehension of access and authorization levels, as well as the consequent threats it provides, especially when we are talking about access to third parties, a situation in which the policy in question is commonly used.

The cloud security community has been discussing this since (at least) 2018:

Sept 20, 2018

Scott Piper: Yikes, so I just looked at their privileges, and they request ReadOnlyAccess as the easiest way, which is way more data than they need, as that let’s them read all of the files out of your S3 buckets and some other resources, as opposed to just the metadata.

Jan 5th, 2022

Andrey Devyatkin: A request that we get from almost every one of our customers is a read-only IAM policy so developers and operators can browse production safely.

Feb 14th 2023

Caleb Tennis: I’m looking for a list of AWS IAM api actions that are data specific vs management actions. The context is to have policy that limits infrastructure tools from being able to access data directly (think “allow s3 bucket actions, but deny s3:GetObject”). Is there a curated list already floating around out there?

Feb 16th, 2023

heath: Howdy team - At a new org, we’re looking at rescoping our Security IAM roles across our AWS Org. Trying to avoid the ReadOnlyAccess trap that is currently in use. Does anyone have any good links for leading practices on setting that up fresh or reference policies around a Security Read-only role?

Phil Sweeney: ViewOnly and SecurityAudit policies are not a bad start.. tends to be missing a few things so you’ll need your own custom additions too

Jason Kao: The few approaches I’ve seen: like what Phil said, ViewOnly and SecurityAudit with a custom additional managed policy. ReadOnlyAccess with an explicit deny policy as a custom supplement. I found this to be easier to manage as we saw issues with ViewOnly and SecurityAudit being updated with new services. Trade-off is making sure the explicit deny denies the proper permissions (or an applicable SCP or Permission Boundary).

The problem is more than just what is metadata vs data. Other actions have significant implications. CloudSplaining went on to define actions that can lead to Privilege Escalation, Credential Exposure, and Resource Exposure. Ian Mckay (a true hero) took that list and added them to his iam-dataset project (here).

None of that solved my immediate problem of “How do I create a policy that allows me to audit the environment fully but not have access to customer data?"

What is the Sensitive Actions Repo

The sensitive_iam_actions repo is a machine-readable (YAML) file that enumerates the actions that can lead to:

  • CredentialExposure
  • DataAccess
  • PrivEsc
  • ResourceExposure

Explicit Opt-in vs. explicit Opt-Out

So our options are to explicitly define all the services and their Get* List* Describe* actions, or leverage the AWS managed policy (which only in the case of ReadOnlyAccess seems to get updated).

I’ve decided the most straightforward approach was to be over-permissive on my allow statements and then pair back access via explicit deny statements. The yaml file can be processed to create deny statements for use in policies.

There are a few problematic actions that can lead to data access but also contain critical configuration information. lambda:GetFunction is an example of an action that gives you details about runtimes and environment data but also allows the auditor to download the codebase via the pre-signed URL returned.

What does this mean for you?

If you’re still reading this, you’re probably disappointed at lack of Snark ‘n Memes. Really this post is to raise awareness. I don’t know enough about every service to know what’s considered data vs metadata. Hell, AWS can’t even answer that, so it falls on us in the cloud sec community to figure it out.

Please, if you know of or learn about new data access, privilege escalation, resource or credential exposure possibilities using these AWS actions, please send me a pull request. If you want to start leveraging these files for your own projects, feel free to do so. And by all means drop me a line - chris at primeharbor dot com - if you do use it and I’ll let you know about any major updates.

Service Analysis of ReadOnlyAccess, ViewOnlyAccess, and SecurityAudit

We pull the JSON down for three policies and run them through little shell magic:

cat ReadOnlyAccess.json | jq .Statement[0].Action[] -r | awk -F: '{print $1}' | sort | uniq
  • ReadOnlyAccess.json: 261
  • SecurityAudit.json: 160
  • ViewOnlyAccess.json: 160

The services in SecurityAudit & ViewOnlyAccess are the same.

In the ViewOnlyAccess not in ReadOnlyAccess:

  1. comprehendmedical
  2. deepracer
  3. docdb-elastic
  4. finspace
  5. geo
  6. honeycode
  7. kafka-cluster
  8. quicksight
  9. s3-outposts

110 services in ReadOnlyAccess but not in ViewOnlyAccess. You’re blind to all of these services if you rely solely on ViewOnlyAccess:

  1. amplify
  2. apigateway
  3. appconfig
  4. applicationinsights
  5. appstream
  6. aps
  7. arc-zonal-shift
  8. artifact
  9. aws-portal
  10. backup-gateway
  11. billing
  12. billingconductor
  13. budgets
  14. cassandra
  15. ce
  16. chatbot
  17. cleanrooms
  18. cloudhsm
  19. codeguru-profiler
  20. codeguru-reviewer
  21. codestar-connections
  22. codestar-notifications
  23. compute-optimizer
  24. consoleapp
  25. consolidatedbilling
  26. customer-verification
  27. databrew
  28. deepcomposer
  29. devops-guru
  30. discovery
  31. dlm
  32. drs
  33. ec2messages
  34. elemental-appliances-software
  35. emr-containers
  36. emr-serverless
  37. evidently
  38. fis
  39. freertos
  40. freetier
  41. gamesparks
  42. groundstation
  43. healthlake
  44. identity-sync
  45. identitystore
  46. identitystore-auth
  47. imagebuilder
  48. importexport
  49. internetmonitor
  50. invoicing
  51. iot1click
  52. iotfleethub
  53. iotfleetwise
  54. iotroborunner
  55. iotwireless
  56. ivs
  57. ivschat
  58. launchwizard
  59. lookoutvision
  60. m2
  61. macie2
  62. mediaconvert
  63. mgh
  64. mgn
  65. mobileanalytics
  66. mobiletargeting
  67. monitron
  68. networkmanager
  69. nimble
  70. notifications
  71. notifications-contacts
  72. oam
  73. omics
  74. osis
  75. outposts
  76. payment-cryptography
  77. payments
  78. pi
  79. pipes
  80. polly
  81. proton
  82. purchase-orders
  83. rbin
  84. refactor-spaces
  85. resiliencehub
  86. resource-explorer-2
  87. route53-recovery-cluster
  88. route53-recovery-control-config
  89. route53-recovery-readiness
  90. rum
  91. s3-object-lambda
  92. sagemaker-groundtruth-synthetic
  93. savingsplans
  94. scheduler
  95. servicecatalog
  96. servicediscovery
  97. signer
  98. sms-voice
  99. ssm-contacts
  100. ssm-incidents
  101. sso-directory
  102. supportplans
  103. sustainability
  104. swf
  105. tax
  106. timestream
  107. tnb
  108. vpc-lattice
  109. workmail
  110. workspaces-web
Come on AWS, can we please get a single team to own this and ensure some level of consistency for customers?