3 ms·
In the new console 1. Why are Credentials under API manager? 2. For API keys, OAuth 2.0 client IDs, Service accounts etc, you should add a "Last Used Date" 3
by boundlessdreamz 11y ago
In the new console
1. Why are Credentials under API manager?
2. For API keys, OAuth 2.0 client IDs, Service accounts etc, you should add a "Last Used Date"
3. I have no idea what the service account email address listed in the Credential page is used for
4. How do I do more fine grained permissions? i.e I want a team member to have access to GCE but not Big Query. To view Storage but not delete it etc?
- boulos 11y ago1. Because Google (it's not just the Google Cloud console). 2. Good point. I'll see why that isn't the case (I agree strongly, it'd be nice to know if this hasn't been used so you can revoke it). 3. A lot of systems require a user/email to identify the "person" taking the action. So this one is a crazy auto generated one for you. You didn't say it, but I'd love to be able to name them (like "Default GCE Service Account" or "Service Account for that Binary I built for deploying stuff"). 4. This is something Google Cloud is behind on and we're working on it. For Storage (and PubSub) there actually are much finer grained ACLs (and you could add them as just a VIEWER role, etc.). I don't recall if we yet support the "Bob can use GCE but not BigQuery". Expect updates here soon. Edit: more blank lines
- boundlessdreamz 11y ago1. Didn't get that. IMO Enabling/disabling APIs should be a separate menu item from Credentials. 2. Ok. 3. Yeah. Naming is a start. I also want to know what does it have access to. 4. Yeah. It's quite messy. Also there are Service Accounts in "Credentials" and also in "Permissions". There are multiple "Google APIs service account" in Permissions. I have no idea what they are for and what does it have access to