Dear CF community,

I'm pleased to announce that the Diego team is nearing completion of our
initial track of work to enable SSH access to app instances running on
Diego. We've recently published some preliminary versions of the Diego-SSH
CLI plugin at https://github.com/cloudfoundry-incubator/diego-ssh/releases,
and I've posted some instructions for developers and operators in the Diego
Design Notes, at
https://github.com/cloudfoundry-incubator/diego-design-notes/blob/master/ssh-access-and-policy.md
.

For a CF+Diego deployment with SSH already enabled and publicly routable,
accessing a CF app instance over SSH is as simple as running cf ssh
<app-name> after installing the CLI plugin. The plugin also supports a -i
option to target other instance indices and a -L option to forward local
ports, and we expect to add a cf scp command soon as well for bidirectional
file transfer.

It's also possible to use the built-in ssh and scp clients on Linux and OS
X to access instances. For more details on how to use those clients, please
see the design notes linked above or the more extensive documentation for
the CF and Diego authenticators on the Diego-SSH repository:
https://github.com/cloudfoundry-incubator/diego-ssh.

If you're using the steps in the diego-release README
<https://github.com/cloudfoundry-incubator/diego-release/blob/develop/README.md>
to deploy it and CF to BOSH-Lite, this SSH functionality should all just
work for you automatically. If you're operating on a different
infrastructure, you will have a few values to configure in your BOSH
deployment manifests, and, depending on your environment, a load balancer
to provision in front of Diego's SSH proxies. Again, the design notes cover
the basic manifest properties and infrastructure setup required to give
access to CF app instances.

Version 0.1.2 of the Diego-SSH plugin also provides commands for adjusting
the SSH policy on CF apps and spaces through Cloud Controller. In
particular, users can employ those commands to enable and disable SSH both
on an individual app and on an entire space. Operators can separately
choose whether to allow SSH access via a BOSH-configurable parameter in
Cloud Controller's configuration.

Finally, we realize that unfettered SSH access to instances is something of
a double-edged sword: while it enables interactive inspection and
experimentation inside an app instance, it also makes it possible to build
'snowflake' instances that will melt whenever the platform restarts them.
To prevent the creation of such snowflakes, we propose to implement a
restart policy for CF app instances: after executing a command, concluding
an interactive session, or copying a file into an instance, that instance
will be restarted. Forwarding ports and copying files out will not trigger
a restart, though. Cloud Controller admins will be able to opt individual
spaces out of this restart behavior, to allow developers greater inspection
of and experimentation on their apps in those spaces. We haven't yet
introduced this behavior, but it's among the last pieces of work we intend
to do before we consider this initial batch of SSH work complete.

If you're interested in the progress of the remaining stories we currently
have planned for SSH access, please look for them in the Diego tracker
<https://www.pivotaltracker.com/n/projects/1003146> with the 'ssh' label.


Thanks,
Eric Malm, CF Runtime Diego PM