Proxy Enforcer Protection - Host Services, Host Wrap, or PAM Plugin

[stewartshea]

There are a few deployment options for the proxy enforcer configuration and using the host services might be simplest but also provides a lack of visibility into the egress traffic.

Perform some testing to determine wither a whole host wrap or pam module is a better approach.

• [x] test using the external network definition in the existing policy
• [x] test and document findings with host wrap
• [ ] create policies to support DXC management
• [x] document installation steps

We aren't going to do PAM testing as host wrap works and is easier to manage.

[stewartshea]

With regards to the host-service configuration, I realised why the "same-same" policy was working; basically it said that "anything in this namespace can talk to resources in this namespace"... but we had also defined the Lab OpenShift Cluster as an external network, thus allowing any traffic from that "external network" into the database. So... that part is explained and that policy is removed.

Here's what isn't clear. With that external network removed (since it is managed by Aporeto)... why do PU's show up as from "somewhere" when they try to connect to the host service in this namespace?

The enforcer should be recognizing them from the cluster namespace instead of "somewhere"... I think we need to figure this out before we get into looking at full host mode configuration

[stewartshea]

Aporeto advised that the source enforcers need the destination managed network added to their profile, the following details apply to that testing.

The Destination The enforcer that is running haproxy with the host service is: [hostip/32] Discovery mode is ON in the this destination namespace

The Source When [hostip/32] is added as a managed network [both tcp/udp] on the OpenShift Lab Cluster Enforcer Profiles, traffic does not egress from the source pod. I see NO rejected flows, and only accepted dns lookups. When [hostip/32] is removed as a managed network on the OpenShift Lab Cluster Enforcer Profiles, traffic does successfully pass from the source pod, and the destination is identified as any-network. I do see permitted flows to the destination.

[stewartshea]

I'd rather not test the PAM solution, it's not ideal for our use case due to the limitations of sandboxing the user session vs the process.

[stewartshea]

So, the Service Dependency and Service configuration was already validated by @sbarre-esit with Aporeto. I also tested this and it's a viable method, and I do not believe we need or want to change anything within our namespace configuration at this point in time.

I created a slide deck that I shared with the team that outlines some of the limitations of this approach, however, it seems to be the only way forward at this time.

While NR can test this solution as it is currently, a better version of this solution is to use full host protection on the enforcer / proxy host, which also allows the NR team to control the egress traffic from the proxy host. The solution, as it stands right now, is only controlling / securing the single haproxy process on the ingress side of things.

@NickCorcoran @cvarjao @mitovskaol what are your thoughts on the above?

Separately, Aporeto is starting a thread on some other proxy agent design ideas that they have, but I have zero idea if these are under development or in the inception / idea phase. I'm not sure we can wait for that to move forward.

[stewartshea]

I believe we've deferred the host-wrap config down the line so that we can push some of the zoneb pilots into production.

[stewartshea]

We've picked this up again since individual host services will be deprecated. Testing as been positive. I need to work with @sbarre-esit to help define the appropriate network access policies for all of the ops management requirements and we will be good to go.

[stewartshea]

@sbarre-esit I've got some current policies running in /bcgov/apps/nr/non-prod/calgary

I'll need to understand the network interface names that you want to exclude so that we can put them into the enforcer profiles and then restart the enforcers.

Can you look at the Network Access Policies and determine what other rules your team may need? At some point we need to turn off the temp-all policy, and possibly look at refining any of the existing ones.

[StevenBarre]

Emailed @stewartshea the list of interfaces to ignore and the existing firewall rules for the PROD interface.

[stewartshea]

so the ignored interfaces doesn't do what we thought it would. The intent of that feature is to ignore internal software bridges in certain k8s setups.

In place of this, we have added a list of MGMT and BUR network ranges to the ignored network list. Awaiting feedback from DXC whether this is functional.

[stewartshea]

I sill need to review existing failed ICMP and connection requests per Stephens comments.

[stewartshea]

I've added the ICMP (any) rule for proxies and cleaned up a couple policies (name typos or direction reversals)... any other denied flows are either a) might not have been specified in the original ruleset, or b) typos in the policy

I think we are in a much better position