Skip to content
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

Broaden standard S3 read permissions to include all Get useful get operations #499

Open
andrewpatto opened this issue Nov 15, 2024 · 5 comments
Labels
change request infrastructure Label this for automatically get onto infrastructure project board

Comments

@andrewpatto
Copy link
Member

There is a broader scope of S3 permissions now

GetObjectAttributes
GetObjectTagging

When we are doing a reasonably broad share objects from one bucket to another say (for general services that might need access) - I suggest we include the wider set of Get permissions.

Clients don't have to use them - but for instance - GetObjectAttributes can be used to list the checksums of a multipart upload which might be useful to something.
Same with tags - unless we have a reason that we would want to prevent clients from seeing tags - this leaves it up to them as to whether they want to copy them or not.

@andrewpatto
Copy link
Member Author

Similarly, if the bucket in questions is versioned - we should have

s3:GetObjectVersion
s3:GetObjectVersionAttributes

because clients in general might be interested in looking at the history of an object

@andrewpatto
Copy link
Member Author

This is only in a scenario where we have "unknown" but trusted clients.. i.e. shares between two of our own prod accounts..

@victorskl
Copy link
Member

@andrewpatto
Copy link
Member Author

This turned out to bite us with a rclone copy (orchestrated from prod - copying uom-data to wehi).

Suggest we prioritise this - at least as far as the permissions shared from prod pipeline in uom-data - shared at an account level to prod.

@andrewpatto andrewpatto added change request infrastructure Label this for automatically get onto infrastructure project board labels Dec 9, 2024
@andrewpatto
Copy link
Member Author

I have manually changed the policy statement in pipeline-prod-cache-503977275616-ap-southeast-2
to

{
            "Sid": "prod_lo_access",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::472057503814:root"
            },
            "Action": [
                "s3:List*",
                "s3:GetObject",
                "s3:GetObjectAttributes",
                "s3:GetObjectTagging",
                "s3:GetObjectVersion",
                "s3:GetObjectVersionTagging",
                "s3:GetObjectVersionAttributes",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "arn:aws:s3:::pipeline-prod-cache-503977275616-ap-southeast-2/*",
                "arn:aws:s3:::pipeline-prod-cache-503977275616-ap-southeast-2"
            ]
        },

so would be good to have this set permanently for the next terraform deploy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
change request infrastructure Label this for automatically get onto infrastructure project board
Projects
None yet
Development

No branches or pull requests

2 participants