4 ms·

I am not even sure what all the fuss is about. AWS IAM has the exact same “issue” where an IAM principal can be allowed to access a resource without asking the

I am not even sure what all the fuss is about. AWS IAM has the exact same “issue” where an IAM principal can be allowed to access a resource without asking the party in question. This model is used because otherwise providing permissions becomes extremely difficult, and users are more likely to throw away the entire concept and settle for one common set of credentials for all users across the project (in the form of a common Google account in case of GCP, or the root user credentials in AWS.)

dannyw 4y ago
This is not the issue.
Ephil012 4y ago
The issue is different from this. Allowing someone within a company to access a resource without asking them is not as big of a deal. The issue here is people outside your company can add you to projects without consent. Imagine you're a malicious actor and want to spam some company's Google Cloud Dashboard. You could just create a 100 different projects and add the company's users to those projects automatically, even though you're not part of that company. Those projects can never be removed or deleted from the dashboard. So every user at the company you're trying to spam can never get rid of it (without Google support intervening maybe). Or let's say you're a malicious actor trying to get someone in trouble. You could create a Google account and hide all traces of who created it. Then you could just create a project doing something illegal (e.g. hosting illegal content) and then add someone to the project. When the authorities find out about the project, the person you're targeting will get investigated for hosting illegal content.
- judge2020 4y ago
  > The issue here is people outside your company can add you to projects without consent. Same for AWS, granting an identity in another account access to resources in your own AWS project also requires no approval on the other side. The issue you seem to have with Google is that it's verbose about showing everything you have access to. As for the company scenario, this is effectively not an issue for Google Workspace-enabled domains since your default project list shows projects under your domain (if you're not parented to gmail.com).
  - Ephil012 4y ago
    I saw another comment which said this wasn't quite the case. https://news.ycombinator.com/item?id=34193624 https://news.ycombinator.com/item?id=34193624 Even if it is the case, it is still an issue because it can be used for abuse. If you wanted to pin abuse on someone you just need to add them to the project doing something illegal. Google tends to be trigger happy about banning so it could affect someone. I bet there are avenues for companies to deal with a situation like this, but it still affects individuals which is a big problem. Especially if your personal account gets banned. I'd also argue that it's a spam issue for companies (albeit less than it is for individuals). You may not see it by default for companies, but it will still appear in some lists throughout the UI probably. I think honestly both AWS / GCP should ask for permission to be invited when you're adding someone outside your company.
deleted 4y ago
[deleted]
jpalomaki 4y ago
I guess in addition to spam, there’s the risk of getting your Google account associated to some shady project. This should not cause any trouble, but sometimes Google’s algoritms can be ”trigger happy” when trying to stop abuse.
frx 4y ago
> AWS IAM has the exact same “issue” where an IAM principal can be allowed to access a resource without asking the party in question. This is not correct. This would only work if the resource is in the same AWS account. For cross account access, both the principal and the resource need to allow each other. See: https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-iam/ https://aws.amazon.com/premiumsupport/knowledge-center/cross...
- judge2020 4y ago
  Technically, but this is more about how 'Account B Admin' must define who (user/principal) can access the resources Account A has already given Account B access to. The difference I see here is that it's not an invite system; Account A does not notify Account B of its new permissions when it grants them, and Account A is not notified when Account B's administrator has defined an access policy for those resources.
- owenmarshall 4y ago
  I think the concern is less technical and more policy. I might be able to sts:AssumeRole to any number of roles created by bad cloud engineers that allowed my account instead of another. But - ignoring that it requires exceptional luck to find the right account/role pair - it takes explicit action on my part to move into their account. At the end of the day, I exchange my credentials for those in another account, and that action is logged in my account, theirs, and with AWS. The concern here is this sharing happens without me doing anything. What happens if I get added to an account whose admin cries foul to Google? Or if their account is flagged for violating GCP terms? Given Google’s history, I’d be worried too.

dannyw 4y ago

This is not the issue.

Ephil012 4y ago

The issue is different from this. Allowing someone within a company to access a resource without asking them is not as big of a deal. The issue here is people outside your company can add you to projects without consent. Imagine you're a malicious actor and want to spam some company's Google Cloud Dashboard. You could just create a 100 different projects and add the company's users to those projects automatically, even though you're not part of that company. Those projects can never be removed or deleted from the dashboard. So every user at the company you're trying to spam can never get rid of it (without Google support intervening maybe). Or let's say you're a malicious actor trying to get someone in trouble. You could create a Google account and hide all traces of who created it. Then you could just create a project doing something illegal (e.g. hosting illegal content) and then add someone to the project. When the authorities find out about the project, the person you're targeting will get investigated for hosting illegal content.

judge2020 4y ago
> The issue here is people outside your company can add you to projects without consent. Same for AWS, granting an identity in another account access to resources in your own AWS project also requires no approval on the other side. The issue you seem to have with Google is that it's verbose about showing everything you have access to. As for the company scenario, this is effectively not an issue for Google Workspace-enabled domains since your default project list shows projects under your domain (if you're not parented to gmail.com).
- Ephil012 4y ago
  I saw another comment which said this wasn't quite the case. https://news.ycombinator.com/item?id=34193624 https://news.ycombinator.com/item?id=34193624 Even if it is the case, it is still an issue because it can be used for abuse. If you wanted to pin abuse on someone you just need to add them to the project doing something illegal. Google tends to be trigger happy about banning so it could affect someone. I bet there are avenues for companies to deal with a situation like this, but it still affects individuals which is a big problem. Especially if your personal account gets banned. I'd also argue that it's a spam issue for companies (albeit less than it is for individuals). You may not see it by default for companies, but it will still appear in some lists throughout the UI probably. I think honestly both AWS / GCP should ask for permission to be invited when you're adding someone outside your company.

deleted 4y ago

[deleted]

jpalomaki 4y ago

I guess in addition to spam, there’s the risk of getting your Google account associated to some shady project. This should not cause any trouble, but sometimes Google’s algoritms can be ”trigger happy” when trying to stop abuse.

frx 4y ago

> AWS IAM has the exact same “issue” where an IAM principal can be allowed to access a resource without asking the party in question. This is not correct. This would only work if the resource is in the same AWS account. For cross account access, both the principal and the resource need to allow each other. See: https://aws.amazon.com/premiumsupport/knowledge-center/cross-account-access-iam/ https://aws.amazon.com/premiumsupport/knowledge-center/cross...

judge2020 4y ago
Technically, but this is more about how 'Account B Admin' must define who (user/principal) can access the resources Account A has already given Account B access to. The difference I see here is that it's not an invite system; Account A does not notify Account B of its new permissions when it grants them, and Account A is not notified when Account B's administrator has defined an access policy for those resources.
owenmarshall 4y ago
I think the concern is less technical and more policy. I might be able to sts:AssumeRole to any number of roles created by bad cloud engineers that allowed my account instead of another. But - ignoring that it requires exceptional luck to find the right account/role pair - it takes explicit action on my part to move into their account. At the end of the day, I exchange my credentials for those in another account, and that action is logged in my account, theirs, and with AWS. The concern here is this sharing happens without me doing anything. What happens if I get added to an account whose admin cries foul to Google? Or if their account is flagged for violating GCP terms? Given Google’s history, I’d be worried too.