-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Add IAM support to APIs which support it #1679
Comments
A gentle ping on this, given that IAM is now GA: is there an IAM API coming? Any chance the Pub/Sub IAM API might be brought up to date. |
@kir-titievsky PR #2031 seems to be related but has not seen updates for a few months. |
@lukesneeringer How would you prefer that I factor out the existing
|
Good question. My instinct is that I would prefer not have an excessive number of sub-projects, and to put it in a That is a loose preference though and I am happy to be persuaded otherwise. (If this were day 1, I would have preferred it have been |
I'm find with putting it in |
What about putting it all in |
@dhermes I'd prefer to keep code that hits any non-auth API endpoint outside of google-auth (I was actually really wary of adding |
gax/core seems like the right spot for this IMO. |
I'd vote for |
Most of the code will be in the "common" bits: schlepping the policy resource into / out of the Python object, creating various principal iDs, etc. See #3188. |
@tseaver To answer a prior question, I am fine with additive changes to core. What I want to move away from is sweeping refactors like what we did with |
FYI looks like most of the IAM implementations (not just pubsub) will break with the introduction of custom roles which is happening within the next month (already some customers in alpha). Fortunately the solution is simple. Stop maintaining individual sets for each role and instead maintain one dict of sets which maps from roles -> members. Then make property shortcuts use the new "bindings" property to maintain backwards compat. |
Wait, what? This is pretty critical information. Tagging @bjwatson, @omaray for awareness.
Could we see an example? |
@lukesneeringer I have provided an example on python on @tseaver 's CL, which is how I had it set up in my proposal for #2031 . I don't know about Node or PHP since I don't know those languages, but we should make sure of that. In python it could be done backwards compat like this:
To support custom roles at the very least you need to support arbitrary role strings and not limit the role strings that you parse out of policy bindings. To fully support custom roles, you'll need to support several more API endpoints, see here: https://cloud.google.com/iam/docs/creating-custom-roles they unfortunately aren't listed in the discovery doc yet, I suspect because they are still under whitelist. There's a design questions about whether or not these endpoints belong on a separate Additionally it doesn't look like there's any support for |
@elibixby The bits of your proposal which add a common subclass for the implementation of those API methods are trickier to address: the endpoints are not consistent across resource types: |
@tseaver This makes it difficult/slow to implement IAM for a new API. One platform should standardize the implementations. In this case it is Pub/Sub which is doing things correctly and storage which is the oddball since the former is a OP API and the latter is not. So new APIs should follow the pattern of Pub/Sub. As a potential user of this library I have avoided it for a while because it didn't have IAM on APIs that supported it, and I needed, and used apiary instead. For example resource manager: also a OP API that follows the same implementation as pubsub. It's really critical to reduce the amount of time it takes to add support for IAM to new APIs, since all new OP APIs that rollout must have such support now, and I think a Mixin is the best way of doing this. That said it can definitely be addressed in a follow-up PR. I just wouldn't consider this issue closed until such a strategy is in place. |
Maybe it would work out, if storage is truly the only exception. I don't think there will be any point in subclassing for storage, rather than just re-implementing the same set of API methods. |
@elibixby I want to follow up on something you said earlier.
I am worried about the potential that something is coming out that will break our libraries, and I still do not understand what the change is or how it will break the library. Can we set up a meeting (internally) to discuss? I want to figure out what, if anything, cross-language action items are. |
(copied from googleapis/google-cloud-node#1192, which is funnily-enough exactly true for
gcloud-python
, too).IAM is currently buried inside of our Pub/Sub code, but should be abstracted to be used with any API that supports it:
The text was updated successfully, but these errors were encountered: