5 ms·

I'm not sure what the hoo hah is about. All that's changed is that this role is now visible in IAMS and any API calls by Amazon support tools will be logged in

I'm not sure what the hoo hah is about. All that's changed is that this role is now visible in IAMS and any API calls by Amazon support tools will be logged in AWS CloudTrail - I don't think AWS have any more access now than they did before. It's obvious to anyone who has had problems with any AWS services (lambda functions that couldn't be deleted, non properly propagating/operational services) that support has access to them via their tools. https://docs.aws.amazon.com/awssupport/latest/user/using-service-linked-roles-sup.html https://docs.aws.amazon.com/awssupport/latest/user/using-ser...

gonzo41 5y ago
But can it override and explicit wildcard deny modification policy in a Bucket!
- gunapologist99 5y ago
  Yes. As I wrote in https://news.ycombinator.com/item?id=29663566 https://news.ycombinator.com/item?id=29663566, service accounts are not constrained by customer bucket policies. In fact, not even SCP's are restricted by service-linked roles: "SCPs do not affect any service-linked role. Service-linked roles enable other AWS services to integrate with AWS Organizations and can't be restricted by SCPs." https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html https://docs.aws.amazon.com/organizations/latest/userguide/o...
skywhopper 5y ago
The policy in question had “s3:GetObject” permission to “*” added for a few hours. And CloudTrail logging doesn’t capture GetObject API requests by default. This role is specifically for metadata only access. Yes, service teams have behind-the-scenes escalation tools for bugs on the backend, but the more numerous front-line support staff should only be able to view metadata. The GetObject permission would have let them view actual potentially sensitive data.
- tills13 5y ago
  You really shouldn't be storing "potentially sensitive data" in a bucket unencrypted, though.
  - throwaway984393 5y ago
    The problem is nobody who is getting upset about this had any reasonable expectations to begin with. They're just now realizing they might need to protect their data against attackers inside AWS, and now they're caught with their pants down, so cue the hand-wringing.

gonzo41 5y ago

But can it override and explicit wildcard deny modification policy in a Bucket!

gunapologist99 5y ago
Yes. As I wrote in https://news.ycombinator.com/item?id=29663566 https://news.ycombinator.com/item?id=29663566, service accounts are not constrained by customer bucket policies. In fact, not even SCP's are restricted by service-linked roles: "SCPs do not affect any service-linked role. Service-linked roles enable other AWS services to integrate with AWS Organizations and can't be restricted by SCPs." https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html https://docs.aws.amazon.com/organizations/latest/userguide/o...

skywhopper 5y ago

The policy in question had “s3:GetObject” permission to “*” added for a few hours. And CloudTrail logging doesn’t capture GetObject API requests by default. This role is specifically for metadata only access. Yes, service teams have behind-the-scenes escalation tools for bugs on the backend, but the more numerous front-line support staff should only be able to view metadata. The GetObject permission would have let them view actual potentially sensitive data.

tills13 5y ago
You really shouldn't be storing "potentially sensitive data" in a bucket unencrypted, though.
- throwaway984393 5y ago
  The problem is nobody who is getting upset about this had any reasonable expectations to begin with. They're just now realizing they might need to protect their data against attackers inside AWS, and now they're caught with their pants down, so cue the hand-wringing.