[Platformone] [EXT] Re: Riddle me this, Batman (odd things in up-prod)
Jonathan Rickard
jrickard at redhat.com
Thu Dec 5 01:01:11 UTC 2019
Tim,
The bastion node in C1 is a windows virtual machine that must be accessed
via Guacamole and is used as a legit jump/deploy server. As stated by Jon
and Dean - the ocp-bastion's only purpose is to deploy OpenShift - we could
probably rename it to make it easier for folks to understand. In our early
deployments this node was a true jump box as well, and we used it for
executing playbooks and IDM management...etc. Once we moved to the
ci-runner deployment the need for remote access really went away. The
server that Dean stood up (up-prod-bastion) is more of a management server,
which is where we're managing IDM access..etc from.
In C1, we break policy by implementing a "deploy" node in the environment
so we have to use a container that performs the same functions. This
container is run by the Jenkins instance, provided by the C1 team.
Hopefully that clears things up
jonny
Jonathan Rickard, RHCA
Principal Consultant, NAPS
Red Hat Remote - Texas <https://www.redhat.com/>
jonny at redhat.com
M: 210-862-9739
<https://www.redhat.com/>
On Wed, Dec 4, 2019 at 11:43 AM Jonathan Hultz <jhultz at redhat.com> wrote:
> Tim,
>
> The OCP_Bastion is necessary to deploy the OCP 3.11 cluster. It holds a
> specific version of ansible and inventory file that Openshift deploys from.
> The CI-Runner triggers the build but its fully automated and it should have
> zero hands on keyboard access.
>
> On Wed, Dec 4, 2019 at 11:29 AM Dean Lystra <dlystra at redhat.com> wrote:
>
>> IMO a VPN solution would be the most preferred option. This would be up
>> to the decision makers to go this route. We used to have OpenVPN in our
>> VPCs, but I am unsure why we no longer use it.
>>
>> On Wed, Dec 4, 2019, 8:21 AM Miller, Timothy J. <tmiller at mitre.org>
>> wrote:
>>
>>> I wouldn't expect a public IP into a private subnet, and I'm wouldn't be
>>> comfy with port forwarding into it either.
>>>
>>> I sense a broken concept of operations here. As currently defined in
>>> IaC, ocp-bastion is useless or redundant:
>>>
>>> - It's in the private subnet and unreachable from any admin console by
>>> the current SG anyway. A VPN is required to reach it.
>>>
>>> - OTOH, if we have a VPN, we can whitelist admin consoles via the VPN in
>>> the default SG. This would save a little $.
>>>
>>> - In C1, ocp-bastion is duplicative with the C1 provided bastion. We
>>> can whitelist the C1 bastion in the default SG and again save some $.
>>>
>>> -- T
>>>
>>> On 12/4/19, 09:33, "Nunez, Carlos A [US] (MS) (Contr)" <
>>> Carlos.Nunez2 at ngc.com> wrote:
>>>
>>> AWS will not allow a public IP in a private subnet. No cloud
>>> provider does. The NAT is what translates Private Subnet resources to be
>>> connected to Public Subnet resources.
>>>
>>> V/R
>>> Adrian
>>>
>>> -----Original Message-----
>>> From: Miller, Timothy J. <tmiller at mitre.org>
>>> Sent: Wednesday, December 4, 2019 10:29 AM
>>> To: Nunez, Carlos A [US] (MS) (Contr) <Carlos.Nunez2 at ngc.com>; Dean
>>> Lystra <dlystra at redhat.com>; Kevin O'Donnell <kodonnel at redhat.com>
>>> Cc: platformONE at redhat.com; Feiglstok, Colleen M [US] (MS) <
>>> Colleen.Feiglstok at ngc.com>; Mathew Huston <huston at diux.mil>
>>> Subject: EXT :Re: [EXT] Re: [Platformone] Riddle me this, Batman
>>> (odd things in up-prod)
>>>
>>> That's great, once a VPN into the VPC is active.
>>>
>>> In the meantime...?
>>>
>>> -- T
>>>
>>> On 12/4/19, 09:07, "Nunez, Carlos A [US] (MS) (Contr)" <
>>> Carlos.Nunez2 at ngc.com> wrote:
>>>
>>> Bastion cannot be in a private subnet. That is the EC2 that
>>> admins/devs will connect to at port 22. If it is in a private subnet it
>>> has no way to be public facing and cannot have a public IP assigned to it.
>>>
>>> V/R
>>> Adrian Nuñez
>>> Senior Cloud Architect
>>> NG Email: carlos.nunez2 at ngc.com
>>> Bylight email: carlos.nunez at bylight.com
>>> Cell: (571)230-5289
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Miller, Timothy J. <tmiller at mitre.org>
>>> Sent: Wednesday, December 4, 2019 8:54 AM
>>> To: Dean Lystra <dlystra at redhat.com>; Kevin O'Donnell <
>>> kodonnel at redhat.com>
>>> Cc: platformONE at redhat.com; Feiglstok, Colleen M [US] (MS) <
>>> Colleen.Feiglstok at ngc.com>; Mathew Huston <huston at diux.mil>; Nunez,
>>> Carlos A [US] (MS) (Contr) <Carlos.Nunez2 at ngc.com>
>>> Subject: EXT :Re: [EXT] Re: [Platformone] Riddle me this, Batman
>>> (odd things in up-prod)
>>>
>>> Is that one up-prod-bastion?
>>>
>>> I'm putting an issue against platform-infrastructure. The
>>> bastion is broken in a couple ways:
>>>
>>> - inbound SG rule defaults to `{{ cidr }}` address space, which
>>> resolves out to the VPC addresses
>>> - it's in the private subnet (probably doesn't matter, but helps
>>> humans keep things straight)
>>> - no public IP.
>>>
>>> -- T
>>>
>>> On 12/3/19, 16:34, "Dean Lystra" <dlystra at redhat.com> wrote:
>>>
>>> One bastion host was created for the sole purpose of
>>> allowing access to the IdM CLI. This was done as a quick fix to get the
>>> users created and for administrative purposes. Access to IdM via web
>>> console or CLI is not available from the internet.
>>> onetime is a mystery to me.
>>>
>>> On Tue, Dec 3, 2019, 2:15 PM Kevin O'Donnell <
>>> kodonnel at redhat.com> wrote:
>>>
>>>
>>> Bastion creation is iac, and the other ec2 that’s running in
>>> prod is for acas and was created to scan and will be shutdown after the
>>> scans are done
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Dec 3, 2019 at 3:34 PM Miller, Timothy J. <
>>> tmiller at mitre.org> wrote:
>>>
>>>
>>> - There are three bastion hosts (up-prod-bastion,
>>> up-prod-ocp-bastion, and "onetime"). Of these, I can find only
>>> up-prod-ocp-bastion in the IaC definition. Both up-prod-bastion and
>>> "onetime" look like they were built separately ("onetime" is baselined on
>>> CentOS--which is a giveaway--and up-prod-bastion is
>>> attached to the `bastion-ssh` security group--which AFAICT is also not part
>>> of the IaC).
>>>
>>> I recall someone (Dean?) telling me that there's no BH in
>>> the IaC, but that's not true (see
>>> consumers/up-node-infrastructure/environments/production/group_vars/all/ec2-instances.yml).
>>>
>>> - up-prod-openscap and up-prod-sso-server have a public IP
>>> but its inbound rules permit only traffic from the VPC subnets (
>>> 10.40.0.0/16 <http://10.40.0.0/16>) and the up-ss-vpc gitlab-ci-runner
>>> instance.
>>>
>>> - up-prod-openscap is attached to the up-prod-ocp-nodes SG,
>>> which is doesn't seem right. That opens a bunch of ports that probably
>>> don't matter to a scan host.
>>>
>>> - up-prod-sso-server has a public IP it doesn't need since
>>> traffic is handled by up-prod-sso-elb.
>>>
>>> FWIW, public IPs are assigned to up-prod-bastion,
>>> up-prod-openscap, up-prod-satellite, up-prod-sso-server, and "onetime".
>>> The bastion host and openscap kinda make sense, though you can jump to
>>> openscap from the BH.
>>>
>>> Damnfino what "onetime" is supposed to be.
>>>
>>> I'm not sure which of these or all of 'em should be turned
>>> into issues. Comments?
>>>
>>> -- T
>>>
>>>
>>> _______________________________________________
>>> platformONE mailing list
>>> platformONE at redhat.com
>>> https://www.redhat.com/mailman/listinfo/platformone
>>>
>>>
>>>
>>>
>>>
>>> --
>>> KEVIN O'DONNELL
>>> ARCHITECT MANAGER
>>> Red Hat Red Hat NA Public Sector Consulting <
>>> https://www.redhat.com/>
>>>
>>> kodonnell at redhat.com <mailto:kodonnell at redhat.com%20M:240-605-4654>
>>> M: 240-605-4654
>>> <https://red.ht/sig>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> platformONE mailing list
>>> platformONE at redhat.com
>>> https://www.redhat.com/mailman/listinfo/platformone
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>> platformONE mailing list
>> platformONE at redhat.com
>> https://www.redhat.com/mailman/listinfo/platformone
>>
>
>
> --
>
> JONATHAN HULTZ, RHCSA
>
> SENIOR CONSULTANT
>
> Red Hat Remote US CA <https://www.redhat.com/>
>
> jhultz at redhat.com M: 609-713-9778
> <https://red.ht/sig>
> _______________________________________________
> platformONE mailing list
> platformONE at redhat.com
> https://www.redhat.com/mailman/listinfo/platformone
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/platformone/attachments/20191204/c89e9045/attachment.htm>
More information about the platformONE
mailing list