bastion access/IP conservation

[Adrian Cole]

In clouds where VMs go into private subnets, we still may be
interested in public ip access for reason of running ssh or some other
utility. For example, in Terremark, we assign a public internet
service (port mapping service) to route port 22 (and anything else
needed) to the private ip/port of the server. This is technically a
loadbalancer, but we use it simply to assign public access to a single
node.

The side effect of going 1-1 is that you need a public ip address for
every machine. There are other ways to manage this.

You can make a single port mapping service a bastion, where it maps
multiple public ports on the same ip address, corresponding to ip/22
on the private nodes. This is maintained server-side and the ssh
connections would go to the public ip:2022 -> private:22 or whatever
public port numbering convention. This can be used for anything, not
just ssh, and doesn't require ssh to implement. However, it does
require a port mapping (loadbalancer) service. The overhead of this
is a single public ip for thousands of ports, or the limit of the
loadbalancer config. It may imply a cost overhead if the cloud
service charges based on sockets.

When there's no portmapping service, you can take a connection from
any single machine and use ssh port forwarding to get access to the
others. In this case, the mappings are a side effect of your current
ssh connection where localhost:2022 -> private:22 for example. This
can also be used for any other service besides ssh, but it does
require ssh, and specifically and ssh client/config that supports port
forwarding. The overhead of this is a single ip socket for thousands
of ports. It has no cost overhead beyond the cost of the initial
public ip/port, but is session based so all vms would need to start an
ssh connection before attempting to connect to other machines via ssh.

Both of these have the advantage of a single public ip address serving
port connectivity multiple private nodes. In the case of the
ssh-based bastion, you can even get by with a single port. What this
does to our model though, is a bit interesting. For example. we
should be able to determine how to access a service on a node based on
a portmapper.

Users could ask for the portmapper and get a list of connections by
node/predicate, etc.

Ex. adminSocketsToPing =
computeService.findSocketsForPortOnNodesMatching(22,
inState(running));

Or, we could make a new field on NodeMetadata like adminSockets()
which reflects current state. We could do both.

ex. (not exactly java)
for(IPSocket sshSocket: filter(node.adminSockets,
type(SSH).addressFamily(IPV6)))
mySpecialSshClient.ping(sshSocket);

we could also add to runScriptOptions the ability to select or
override the means by which we attempt to connect.

response = compute.runScriptOnNode(node.getId(), private().port(2022))

Underneath, we could implement this portmapping interface via however
we can, ex. ssh, loadbalancer, etc. depending on what's available in
the cloud.

Thoughts on the interface? I'd like to get something helpful into 1.1
as I'm noticing people are not able to use the ComputeService
interface when using basition setup.

-A

[Kedar Dave]

+1. This is almost a must have for enterprise clouds such as Savvis and Terremark.

--
You received this message because you are subscribed to the Google Groups "jclouds-dev" group.
To post to this group, send email to jclou...@googlegroups.com.
To unsubscribe from this group, send email to jclouds-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jclouds-dev?hl=en.

--
Kedar

[Kedar Dave]

+1 for computeService.findSocketsForPortOnNodesMatching(22,inState(running))
+1 for node.adminSockets as well. Just ttat it sounds a bit confusing to me, just the term adminSockets
+1 for RunScriptOptions.port

--
Kedar

[Andrew Phillips]

> Thoughts on the interface? I'd like to get something helpful into 1.1
> as I'm noticing people are not able to use the ComputeService
> interface when using basition setup.

Could this be included in RunScriptOnNode, or implemented by a
suitable subclass? Configuration information could be injected by
Guice or passed in as arguments...

ap

[Hugo Duncan]

On Tue, 26 Jul 2011 15:49:35 -0400, Adrian Cole <adrian...@gmail.com>
wrote:

> Users could ask for the portmapper and get a list of connections by
> node/predicate, etc.
>
> Ex. adminSocketsToPing =
> computeService.findSocketsForPortOnNodesMatching(22,
> inState(running));

is socket the correct term to be using? proxyPort?

does this assume a single bastion per compute service?

> Or, we could make a new field on NodeMetadata like adminSockets()
> which reflects current state. We could do both.
>
> ex. (not exactly java)
> for(IPSocket sshSocket: filter(node.adminSockets,
> type(SSH).addressFamily(IPV6)))
> mySpecialSshClient.ping(sshSocket);

presumably this returns an ip, port pair? Having a node centric interface
would seem the easiest to use to me.

adminSockets sounds strange to me too - proxyPorts?

What happens in the absence of a bastion? how do you distinguish between
"address the node directly" and "there is a bastion, but the port you
requested is not available on the bastion"?

> we could also add to runScriptOptions the ability to select or
> override the means by which we attempt to connect.
>
> response = compute.runScriptOnNode(node.getId(), private().port(2022))

specifying the transport would seem more useful to me, something like:
compute.runScriptOnNode(node.getId(), via(SSH))

(fwiw, one of the things pallet is aiming for is being able to run script
via amqp)

> Thoughts on the interface? I'd like to get something helpful into 1.1
> as I'm noticing people are not able to use the ComputeService
> interface when using basition setup.

Should the interface be transparent? ie. is client code written with
different paths for clouds using bastions, or is there just some different
configuration up front with client code being indifferent to bastion usage.

--
Hugo Duncan

[ctdean]

As I see to the proposal is something like:
1.  Have a bastion service that tunnels ssh to internal machines.2.
 Add a NodeMetadata field that controls how access a node (public ip, 
  private ip, bastion).
Not that exactly, but similar.
As for the bastion service, it seems like a cool idea but I have no
realopinion.  I suppose there would need to be a way to avoid having
thebastion server/load balancer being a SPOF.
Our own needs are to access a node using a private ip and having a
field(adminAddress? scriptAddress?) would work nicely.  If we added
aNodeMetadata field when would it be set?  During create-nodes ?
On our current project we have clusters that have have no public
portsexcept for an https port.  (They are controlled by a hodgepodge
ofscripts and puppet configs.)
Cheers,Chris Dean