> +Google Cloud Platform uses OAuth which gives a variety of choices how to > authenticate: > + > + * One can ask a user for consent to perform operations in his/her name. > + * One can create a service account and use its private key to authenticate. > + * Unless configured otherwise, programs running on a GCE instance can > perform operations as the project's default service account > ([documentation](https://developers.google.com/compute/docs/authentication)). > + > +You can find all the details in [the > documentation](https://developers.google.com/accounts/docs/OAuth2), while in > these examples we will focus only on service accounts (bullet 2). > + > +To create a new service account: > + > + * Go to the [Developer Console](https://console.developers.google.com/). > + * Choose API & auth > Credentials. > + * Click "Create new Client ID". > + * Select "Service account" and click "Create service ID". > + * Details of the new service account will be displayed. You will also be > able to download the private key for this account, which you will need for > authentication. Make a note of the service account email address - you will > need it to use the account. > + * To keep the examples simple, we use private keys without passwords. It > might be something you will not do in a production environment, but for the > examples run: `openssl pkcs12 -in {downloaded_file}.p12 -nodes -out > gcp-example.pem -passin pass:notasecret`.
Changed the wording. To use it with a password I think one will can use a third-party library to handle P12 files - AFAIK jclouds itself doesn't support it out of the box, but there should be a lot of available libraries. Note that if you store the password on the server for use by automated programs, it only provides security through obscurity - all the data to get the private key is still available to someone who compromises the system. So I guess the answer what people would do in a production environment depends very much on the threat model. I'd expect some people wouldn't care if keys are leaked after the system got compromised (because they would rebuild the whole deployment in such a case) and will store everything without passwords while others would accept only tamper-proof hardware crypto card. By "you might not do in a production environment" I didn't mean this is a crazy thing to do, but it's not something that will work for everyone and I actually don't have the experience if this would work for the majority of people. Maybe it could be formulated better? --- Reply to this email directly or view it on GitHub: https://github.com/jclouds/jclouds-site/pull/98/files#r13905809
