Semantics of TemplateOptions.authorizePublicKey(...) -- esp wrt Google Compute

[Alex Heneveld <al...@cloudsoftcorp.com>]

Hi All-

I'm noticing something strange with google-compute-engine and 
`TemplateOptions.authorizePublicKey(key)`.

I assumed this is meant to allow a user to supply an *additional* public 
key to be authorized on the machine.  Is this right?

In google-compute-engine, if you set this, jclouds is not able to ssh in 
(and provisioning fails) unless you also TO.overrideLoginPrivateKey with 
the corresponding private key, and that becomes the *only* mechanism 
enabled on the machine.  GCE's 
CreateNodesWithGroupEncodedIntoNameThenAddToSet uses this as the 
primary/default mechanism for access:

       // Configure the default credentials, if needed
       if (templateOptions.autoCreateKeyPair() && 
Strings.isNullOrEmpty(templateOptions.getPublicKey())) {
          logger.debug(">> creating default keypair...");
          Map<String, String> defaultKeys = keyGenerator.get();
templateOptions.authorizePublicKey(defaultKeys.get("public"));
templateOptions.overrideLoginPrivateKey(defaultKeys.get("private"));
       }

I think this should be changed so that defaultKeys is installed unless 
*overrideLoginPrivateKey* is set.  And anything the caller supplies in  
templateOptions.getPublicKey()  should be kept, in addition, I think.  
However there is no formal mechanism within TO.authorizePublicKey for 
setting multiple keys.  Although in practice you can for most clouds 
supply multiple public keys, one per line.  (See e.g. how 
TemplateOptionsToStatement  is implemented.)

If we formalize this requirement, that authorizePrivateKey(...) respect 
a multi-line string, then I think it becomes pretty easy to fix this 
problem in GCE, with the above tweak in CreateNodes.... and fix the 
formatting of "sshKeys" in GoogleComputeEngineServiceAdapter accordingly.

Does this seem reasonable?

Are there any other cloud providers who do custom things with the 
"publicKey" in TO?

Best
Alex


-- 
Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. 
 Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
 
This e-mail message is confidential and for use by the addressee only. If 
the message is received by anyone other than the addressee, please return 
the message to the sender by replying to it and then delete the message 
from your computer. Internet e-mails are not necessarily secure. Cloudsoft 
Corporation Limited does not accept responsibility for changes made to this 
message after it was sent.

Whilst all reasonable care has been taken to avoid the transmission of 
viruses, it is the responsibility of the recipient to ensure that the 
onward transmission, opening or use of this message and any attachments 
will not adversely affect its systems or data. No responsibility is 
accepted by Cloudsoft Corporation Limited in this regard and the recipient 
should carry out such virus and other checks as it considers appropriate.

Re: Semantics of TemplateOptions.authorizePublicKey(...) -- esp wrt Google Compute

[Ignasi Barrera <na...@apache.org>]

There are a couple things to consider here: how the
"authorizePublicKey" behaves has never been formalised, and I agree we
should do that. Let's use this thread to come to a consensus we are
all happy with.

I think the main point to discuss is whether jclouds should *always*
create a (hidden) key pair so jclouds itself has access to the node,
or it should just create it *when requested*. The current and more
recent implementations assume the latter, based on how the aws-ec2
provider, which was the most used, behaved (see [1]). DigitalOcean [2]
and GCE [3] assumed similar strategies, which could be described as:

* Do not automatically create a key pair for jclouds if the user
specifies a custom key. If the user provides a public key, just
install it, but don't install an additional (hidden) one created by
jclouds, to be used by jclouds. We assume users want a restricted
access to the nodes they provision.
* If the user does not provide ssh keys and the "auto generate key
pair option" (in DO and GCE) is enabled, then auto-generate a new key
pair for jclouds.

Both approaches have their limitations:

* Always creating a key pair by default may not be desired by users,
as nodes could end up with authorised keys that are not controlled by
them.
* Not creating a keypair for jclouds can leave the node inaccessible
unless the user explicitly provides the corresponding private key
(which makes sense) or the key is already loaded in the ssh-agent.

The latter is the issue you are experiencing, but take into account
that the provided public key is *always* configured (see [4]). What
happens is that jclouds is missing the private key and can't connect
to the node (unless it is already loaded in the ssh-agent).


This said, I think the current approach makes sense (in fact both make
sense), but can be changed if always creating a key pair for jclouds
seems a better idea. There was already JCLOUDS-468 [5] to fix Nova the
same way, but we could reformulate the issue to align all compute
providers to behave the same way.


Regarding the "multiline string proposal", I'd suggest we change the
option to accept a varargs argument. This way the option would be
better understandable and easier to use (most providers don't just
write the authorized_keys file but create keypairs using their API so
we'd have to parse that string), and would still be backwards
compatible.


Let's discuss how we want this to behave!

I.



[1] https://github.com/jclouds/jclouds/blob/master/providers/aws-ec2/src/main/java/org/jclouds/aws/ec2/compute/strategy/CreateKeyPairPlacementAndSecurityGroupsAsNeededAndReturnRunOptions.java#L122-L139
[2] https://github.com/jclouds/jclouds-labs/blob/master/digitalocean2/src/main/java/org/jclouds/digitalocean2/compute/strategy/CreateKeyPairsThenCreateNodes.java#L98-L114
[3] https://github.com/jclouds/jclouds/blob/master/providers/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/compute/strategy/CreateNodesWithGroupEncodedIntoNameThenAddToSet.java#L116-L127
[4] https://github.com/jclouds/jclouds/blob/master/providers/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/compute/GoogleComputeEngineServiceAdapter.java#L155-L158
[5] https://issues.apache.org/jira/browse/JCLOUDS-468

On 29 August 2015 at 03:42, Alex Heneveld
<al...@cloudsoftcorp.com> wrote:
>
> Hi All-
>
> I'm noticing something strange with google-compute-engine and
> `TemplateOptions.authorizePublicKey(key)`.
>
> I assumed this is meant to allow a user to supply an *additional* public key
> to be authorized on the machine.  Is this right?
>
> In google-compute-engine, if you set this, jclouds is not able to ssh in
> (and provisioning fails) unless you also TO.overrideLoginPrivateKey with the
> corresponding private key, and that becomes the *only* mechanism enabled on
> the machine.  GCE's CreateNodesWithGroupEncodedIntoNameThenAddToSet uses
> this as the primary/default mechanism for access:
>
>       // Configure the default credentials, if needed
>       if (templateOptions.autoCreateKeyPair() &&
> Strings.isNullOrEmpty(templateOptions.getPublicKey())) {
>          logger.debug(">> creating default keypair...");
>          Map<String, String> defaultKeys = keyGenerator.get();
> templateOptions.authorizePublicKey(defaultKeys.get("public"));
> templateOptions.overrideLoginPrivateKey(defaultKeys.get("private"));
>       }
>
> I think this should be changed so that defaultKeys is installed unless
> *overrideLoginPrivateKey* is set.  And anything the caller supplies in
> templateOptions.getPublicKey()  should be kept, in addition, I think.
> However there is no formal mechanism within TO.authorizePublicKey for
> setting multiple keys.  Although in practice you can for most clouds supply
> multiple public keys, one per line.  (See e.g. how
> TemplateOptionsToStatement  is implemented.)
>
> If we formalize this requirement, that authorizePrivateKey(...) respect a
> multi-line string, then I think it becomes pretty easy to fix this problem
> in GCE, with the above tweak in CreateNodes.... and fix the formatting of
> "sshKeys" in GoogleComputeEngineServiceAdapter accordingly.
>
> Does this seem reasonable?
>
> Are there any other cloud providers who do custom things with the
> "publicKey" in TO?
>
> Best
> Alex
>
>
> --
> Cloudsoft Corporation Limited, Registered in Scotland No: SC349230.
> Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP
>
> This e-mail message is confidential and for use by the addressee only. If
> the message is received by anyone other than the addressee, please return
> the message to the sender by replying to it and then delete the message from
> your computer. Internet e-mails are not necessarily secure. Cloudsoft
> Corporation Limited does not accept responsibility for changes made to this
> message after it was sent.
>
> Whilst all reasonable care has been taken to avoid the transmission of
> viruses, it is the responsibility of the recipient to ensure that the onward
> transmission, opening or use of this message and any attachments will not
> adversely affect its systems or data. No responsibility is accepted by
> Cloudsoft Corporation Limited in this regard and the recipient should carry
> out such virus and other checks as it considers appropriate.