-
-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stop using action wildcards and start explicitly listing permissions #15
Comments
But... there are a LOT of actions to consider, and it looks like AWS add more over time. I collected a full list of them here: #11 (comment) Here is the current list of actions that match these two wildcards. For
For
Interestingly there are a bunch of other actions involving
Some of those DO match the read-only So yeah, wildcards as currently implemented by this tool are very flawed. |
The bigger problem here is that the terms "read-only" and "read-write" and "write-only" do not actually have defined meanings within the world of S3. That's why I've had so much trouble finding good example policies out there - since the terms don't have a concrete meaning the question I'm asking here isn't actually a valid one. So I need to define what I think read-only, read-write and write-only should mean in the context of this specific tool, then implement and document it. |
Here's a recipe for outputting a full list of S3 operation names using boto3.client("s3").meta.service_model.operation_names |
Here's a JavaScript one-liner which extracts the names AND descriptions from the table of actions on https://docs.aws.amazon.com/AmazonS3/latest/userguide/list_amazons3.html#amazons3-actions-as-permissions copy(
Array.from(
document.querySelector("table").querySelectorAll("tr td:first-of-type")
)
.filter((el) => el.innerText)
.map((el) => {
var name = el.innerText;
var description = el.parentNode.getElementsByTagName("td")[1].innerText;
return `- **${name}**: ${description}`;
})
.join("\n")
);
|
I'm going to pick the ones that look sensible to me and add them - along with a comment describing them - to the |
This site looks very useful: https://permissions.cloud/ |
I tried to use this tool with https://litestream.io/ (the original inspiration for building this) and discovered that the current read-write mode isn't enough, because Litestream needs access to |
Built myself a new tool to help with this: https://iam-definitions.vercel.app/iam/privileges?_sort=rowid&service__exact=s3&_facet=access_level Particularly useful:
|
Splitting this into separate issues, so I can maybe link to them from the documentation. |
New policy designs are all implemented. Need to do a round of testing before I close this issue. |
See #11 (comment)_ for context.
The read-write policy currently uses
"Action": "s3:*Object"
- and the read-only one usesAction": "s3:GetObject*"
.This is pretty gross - surely explicitly listing the allowed actions is better practice?
The text was updated successfully, but these errors were encountered: