🔒 Improve AWS Cloud IAM policy security #839
Conversation
- Scope IAM roles and instance profiles to TowerForge* prefix - Add resource-level restrictions for EC2 operations - Split launch policy into granular statements with conditions - Restrict instance operations to TowerForge-* tagged resources 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
✅ Deploy Preview for seqera-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Thanks, @kenibrewer! Adding Georgi for a dev review and then good to merge. |
There was a problem hiding this comment.
At a glance looks good to me, but I've not really been involved in the AWS Cloud CE work, so I'll defer to @stefanoboriero who is more familiar with the resource management of the AWS Cloud CE
|
Do the same changes need to be made for Enterprise docs too? Or are the pages linked? |
There was a problem hiding this comment.
The main reason why I didn't scope them down by prefix in the docs is that the prefix is actually configurable by Enterprise users (see TOWER_FORGE_PREFIX in https://docs.seqera.io/platform-enterprise/enterprise/configuration/overview), and I wanted to be as generic as possible. If we want to add this to the docs, we should be clear that if you override the default forge prefix this permissions cannot be copy-pasted.
| "arn:aws:ec2:*:*:instance/*", | ||
| "arn:aws:ec2:*:*:volume/*", | ||
| "arn:aws:ec2:*:*:network-interface/*", | ||
| "arn:aws:ec2:*:*:subnet/*", | ||
| "arn:aws:ec2:*:*:security-group/*", | ||
| "arn:aws:ec2:*:*:key-pair/*", | ||
| "arn:aws:ec2:*:*:image/*" |
There was a problem hiding this comment.
Is this really any different than using *? Actions are anyhow not applicable to all resource types, so defining individual resource types still with a star permission doesn't seem to change much the scope of the actual permissions.
For example, with the current config I can't use ec2:RunInstances on a Kinesis stream, because the action already carries the scope of what resource type it can be taken against.
On the other hand I get this might have a placebo effect if someone reads it through without giving it much thought, it seems more scoped.
| "Sid": "AwsCloudLaunchInstances", | ||
| "Effect": "Allow", | ||
| "Action": [ | ||
| "ec2:DescribeInstances", |
There was a problem hiding this comment.
Did you test this? AWS Docs say that using the ec2:ResourceTag/Name condition key is not supported for action ec2:DescribeInstances. See https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonec2.html#amazonec2-actions-as-permissions.
| "Action": [ | ||
| "logs:GetLogEvents" | ||
| ], | ||
| "Resource": "arn:aws:logs:*:*:log-group:*:log-stream:*" |
There was a problem hiding this comment.
Same comment as above, this does not seem to move the needle much in terms of actual permission scopes. However here we could be more specific, since we know the exact log group we're interested into, which is tower/nextflow-run
There was a problem hiding this comment.
Great. Please implement.
| "Action": [ | ||
| "s3:GetObject" | ||
| ], | ||
| "Resource": "*" |
There was a problem hiding this comment.
Leaving the star here is inconsistent with the general approach taken of specify arns, even if the actual scoping outcome is the same. I would either do it everywhere or nowhere
|
I don't have the bandwidth to bring this PR to completion. Can someone else work on this and ping me for a review so I can ensure it meets pre-sales needs? Addressing the specific feedback. It is VERY IMPORTANT in my view to scope things using the To address the |
I'll pick this up and ping you for review |
|
@stefanoboriero @justinegeffen Can we get this re-reviewed and merged? |
5 participants
Summary
TowerForge*prefix instead of wildcard resourcesTowerForge-*instance namingTest plan
🤖 Generated with Claude Code