The standard approach to setting up a bastion server (or jump box) has enough weaknesses already. Managing secure access to your VPC's for hundreds of users and hundreds of servers increases these exponentially. I found the available solutions lacking. Here I briefly cover the issues and present a working production solution immutably deploying ssh bastion access as a stateless service on AWS, managed entirely with Terraform - no build chain, no registries, no secrets management and instantaneous access. The result is a bastion server that isn't there, until the moment a user calls for it and then it can be their special snowflake, just for them, briefly, until it's gone.

1. The Bastion Server That Isn’t
There
- Providing scalable secure access as a
stateless service with Terraform on AWS
Joshua Kite

2. About me:
Joshua Kite -
See my website for links, contact, etc:
www.joshuakite.co.uk
Site Reliability Engineer @ DAZN ‘The Netflix of sport’

3. A Word of thanks
I would like to thank the people who have helped to make this idea a reality and
supported this presentation:
Mike Bristow, Senior Engineer at NeuLion
Piotr Jaromin, Software Engineer; Marco Crivellaro System Architect;
Rick Burgess SRE Manager; Simon Coutts Head of Development at DAZN

4. What is the problem
that we are solving?

5. New Bastion server
New Bastion server is like:

6. <PIcture> ‘no face’ before and after
Old Bastion server is like:

7. So what solutions are
already out there?

8. Bastions on steroids

9. Gravitational Teleport
http://gravitational.com/teleport

10. Aker
https://github.com/aker-gateway/Aker

11. Pritunl Zero
https://zero.pritunl.com/

12. Third party IAM solutions
Some install as a standalone binary, e.g.
https://keymaker.readthedocs.io/en/latest/ (Python)
Some are intended as a script to install a dedicate
server on EC2, e.g. https://github.com/widdix/aws-ec2-
ssh (Python; Bash)

14. What are our limitations?

15. “Take CVS as an example of what not to do; if
in doubt, make the exact opposite decision.”
- Linus on the Git design philosophy

16. Ikebana
(生け花, "living flowers")

23. So what do we aim
for (apart from the
above)?

24. So what is our solution?

25. But how do we control our instances?

26. But what are users logging in with?

27. Deployment

29. That’s great for
RDS But my
services are on
ECS, not EC2!

30. But I use AWS organisations!

31. So what does this look like to my user?
To reach bastion:
ssh-add ~/.ssh/billybob.rsa
ssh billybob@yourbastionservice.com
To reach ecs host:
ssh -J billybob@yourbastionservice.com billybob@yourecshost

35. Version history

36. What does the code look like?
You can use the community module directly or review on Github
● registry.terraform.io/modules/joshuamkite/ssh-bastion-service/aws
● github.com:joshuamkite/terraform-aws-ssh-bastion-service.git

37. Code Features
● What it doesn’t do is almost as important as what it does do.

38. Demo

39. reflections
Since the bastion service host is not running anything interesting besides the
dockerised service it doesn’t really matter if our users can see metadata and we
aren’t overly worried about a guest escape
Unlike a traditional bastion server our users are protected from ssh socket
stealing identity impersonation
Ssh host key is a conscious choice
Pull requests are welcome!

40. Yes DAZN is hiring!

41. Thanks!
Questions?
Joshua Kite
www.joshuakite.co.uk