create property for specifying google-compute project id

[codefromthecrypt]

While parsing project id from the service account in GoogleComputeRestClientModule.supplyProject is helpful to avoid excess configuration, we've learned in keystone that project identifiers are things that should be allowed independently.

You can refer to how keystone specifies and reads tenant id optionally from a property.

actions to take:

1. create org.jclouds.googlecompute.config.GoogleComputeProperties.PROJECT_ID as jclouds.google-compute.project-id
2. change GoogleComputeRestClientModule.supplyProject to use a function class instead of an anonymous one. supplyProject(@org.jclouds.location.Provider final Supplier<Credentials> creds, ReadProjectIdFromPropertyOrParseEmail fn)
3. in ReadProjectIdFromPropertyOrParseEmail, make an @Inject(optional=true) @Named(GoogleComputeProperties.PROJECT_ID) setter. On apply, read this, falling back to the old implementation in `supplyProject.
4. change BaseGoogleComputeApiLiveTest and the pom.xml to optionally read jclouds.google-compute.project-id during test runs.
5. create an expect test that proves that the compute supplier reads this.

cc @mattstep @dralves

[dralves]

I understand the underlying objective behind this issue, but currently the option to specify an alternate project_id would never be used (there is no case that I know of where a project's identity can be used on another project).
I guess later if google implements something close to amazon's IAM this might be useful, but as it stands it's just code that would never be used.

[codefromthecrypt]

This issue is low priority while service account authentication is the only
supported means of authentication in jclouds and only one project id can be
authorized to a service account. When google docs say words like
"currently supports" in context of things, we shouldn't conflate that with
"never happen", especially in a beta API.

Fwiw, service accounts are absolutely in the same ballpark as what you can
do in IAM. I don't disagree with delaying this issue though.

[dralves]

gce service accounts are currently basically aliases, i.e. alternative credentials to the same project, AFAIK IAM does much more than that.
I'm not saying that google will not implement something that will require this, I'm saying that we should take care of that when it happens and not antecipate how they might solve it (for instance it might require fine grained/per api permissions or allowing multiple projects ids per context)

[codefromthecrypt]

Not sure if you've used IAM much. I have. You can create a federated
identity which is pretty much an alias. Same thing with Session
credentials. Unless I am mistaken, you can authenticate via multiple means
to GAE now. Only one option is service account where the project id is
the same as the first part of the email address. Using other mechanisms
implies the need to specify a project id, which is why gcutil requires
this. Am I wrong or am I speculating?

On Sunday, March 10, 2013, David Ribeiro Alves wrote:

gce service accounts are currently basically aliases, i.e. alternative
credentials to the same project, AFAIK IAM does much more than that.
I'm not saying that google will not implement something that will require
this, I'm saying that we should take care of that when it happens and not
antecipate how they might solve it (for instance it might required fine
grained/per api permissions or allowing multiple projects per context)

—
Reply to this email directly or view it on GitHubhttps://github.com/jclouds/jclouds-labs/issues/7#issuecomment-14693769
.

[jclouds]

Anyway if you don't yet understand or see the value, just leave this issue
to me. I finally have a gce account so I can do it. it would be less time
and work than having long meta discussions here and also in pull reviews.

On Sunday, March 10, 2013, Adrian Cole wrote:

Not sure if you've used IAM much. I have. You can create a federated
identity which is pretty much an alias. Same thing with Session
credentials. Unless I am mistaken, you can authenticate via multiple means
to GAE now. Only one option is service account where the project id is
the same as the first part of the email address. Using other mechanisms
implies the need to specify a project id, which is why gcutil requires
this. Am I wrong or am I speculating?

On Sunday, March 10, 2013, David Ribeiro Alves wrote:

gce service accounts are currently basically aliases, i.e. alternative
credentials to the same project, AFAIK IAM does much more than that.
I'm not saying that google will not implement something that will
require
this, I'm saying that we should take care of that when it happens and
not
antecipate how they might solve it (for instance it might required
fine
grained/per api permissions or allowing multiple projects per context)

—
Reply to this email directly or view it on GitHub<
https://github.com/jclouds/jclouds-labs/issues/7#issuecomment-14693769>
.

—
Reply to this email directly or view it on GitHubhttps://github.com/jclouds/jclouds-labs/issues/7#issuecomment-14693895
.

[dralves]

I have only limited experience from IAM, but what I was trying to say is that while IAM allows cross-account API access with possibly different permissions, google for the moment allows to create multiple identities for the same account which are all the same permissions-wise.

That being said there is a situation where the current implementation would fail as I've just noticed that service accounts beyond the first one have an additional key in front of the project id (e.g. my_id-2nsqe58q5ci79v4r7derqfitk543qah1@developer.gserviceaccount.com). This requires additional parsing but still doesn't require to allow to specify a project id.

Now If I'm wrong and if there is of a case where an identity would be able to authenticate to a different project and/or a case where it would not be possible to infer the project id from the identity then +1.

[dralves]

didn't see your response until I posted mine. I'll leave it to you...

[codefromthecrypt]

Cool. Like I said, this change isn't highest priority, but I'll be sure to
show in a test case what I'm discussing when I address it. Ttfn

On Sunday, March 10, 2013, David Ribeiro Alves wrote:

didn't see your response until I posted mine. I'll leave it to you...

—
Reply to this email directly or view it on GitHubhttps://github.com/jclouds/jclouds-labs/issues/7#issuecomment-14694269
.

[codefromthecrypt]

Notes for future implementer of this issue:

Similar to keystone, there are multiple ways to authenticate against gce. Some of which, you can parse the project number from another piece of auth data. Here are the three ways:

Access Token
Refresh Token
Service Account (with impersonation option)

As long as we only support service account and service account remains limited to a single project, we can use the current code as is. At any point where we support other flows or service account becomes not pinned to a single project, this issue needs to be implemented.

For context, every API that has multiple authentication means has resulted in us implementing multiple authentication means so far. For example, keystone, amazon, and cloudstack all expose optional means to choose a non-default authentication system. If one ever uses something besides the service account flow, gce will need this change. I know this as I've asked google if there is a way to query for ones project number last week and they replied no.

In short, while we restrict users to service account flow and service account flows are 1-1 with project number, this issue can stay dormant. If anything changes though, this issue will help whoever that is know exactly what is needed to accommodate specification of a project id without asking me :)