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

On 06 Mar, Gabriele Cerami wrote: 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.