[rdo-dev] RDO infra/TripleO-CI teams integration level on infrastructure

[Gabriele Cerami]

On 06 Mar, Gabriele Cerami wrote:
> https://trello.com/c/xuRVmCDr/622-setup-teardown-tooling-bastion-host
> So the question is: is the bastion host in scope, or we have something
> different in mind when we talked about it ?
> We also more or less agreed that the bastion host will be present only
> on the infra tenant, not on the nodepool tenant, in which it would
> serve to bastion only the te-broker. So the te-broker will be
> completely exposed, and it will have a public ip

I had to see this through in details. Read around more about the bastion
host and implementations. Revisited what I did in the past jobs.
I proceeded with some analysis on the requirements. We currently have 7
servers in our infra
- promoter
- te-broker
- 4 sova instances
- dns

The 4 sova instances are not a problem, they just gather informations,
they are not active on anything and they don't have power to change,
only reporting. Having them compromised is not a big problem. It can
stay outside of the bastion.
We really should have only one so we can simplify and use less floating
ips, but this is an issue for a different sprint.
The dns server is just a forwarding server, again, no data in there and
no changes from it. It also needs to be accessible from the instances
with a floating IP. It has to stay outside of the bastion.
At this point promoter and te-broker share a similar condition: They are
both the only critical servers in their tenant. We prefer not to use a
bastion on the nodepool tenant to not have a bastion handle a single
server. But at this point this is valid for the promoter server too.

So here's my comprehensive scenario and proposal after the analysis. We
can use it as pessimistic approach, discuss on it and see what
trade-offs we need for time and resources constraints, and decide what
to do in this spint, what leave for later, and what we prefer not to
implement:

- A bastion makes sense only with a properly configured firewall.


- We will configure the security groups in this way

** sova instances, ALLOW output to the logs server and repo mirrors.
DENY rest. ALLOW input from all to http port on public ip, from bastion
internal ip to ssh. DENY the rest

** promoter server. ALLOW output to repo mirrors, images server,
containers registry, dlrn api. DENY rest. ALLOW input from bastion to
ssh in internal network. Push promoter logs to log server for exposure.
NO Floating IP.

** dns, ALLOW OUTPUT repo mirrors. ALLOW input tcp/udp 53, SSH only from
bastion host internal ip

** te-broker. ALLOW output to internal tenant and repo mirrors. DENY
rest. Allow input ssh from the public ip for the bastion host in infra
tenant. Port knocking may be used, so only the bastion can open the ssh
and log in.

** bastion host. Allow out to repo mirrors and all the servers it
handles. ALLOW INPUT ssh from all. Maybe with port knocking too.

** instances in nodepool tenant: ALLOW output to repo and registry
mirrors, DENY rest. ALLOW input ssh only from the bastion public ip

I know output whitelisting may be too difficult, so I consider it
a soft requirement.

- The bastion host will act primarily as jump host, so no service
masking, as we don't expose dangerous services. NO PUBLIC KEYS WILL BE
ALLOWED ON THE BASTION HOST. Only proxy ssh or key forwarding will be
allowed.
It will handle the infra servers in the nodepool tenant too, and should
be used for when the test instances in the tenant are put on hold for
live debugging.

Please provide feedback.
Thanks.