Add optional network policy object for deploy of step-certificates

[sshipway]

Description

This update to the helm template for step-certificates allows the optional creation of NetworkPolicy rules.

For users who have a Default-Deny policy rule on their kubernetes cluster (as we do) the normal deploy of a LoadBalancer Service will not be accessible from outside, and a Policy rule is required to permit the traffic.

Documentation is added to the Readme file and the values.yaml for the new available values.

Example

networkpolicy:
  enabled: true
  allow:
  -  "10.0.0.0/8"

In addition a couple of minor yaml formatting changes to make our automated yamllint a little happier.

[CLAassistant]

All committers have signed the CLA.

[maraino]

Hi @sshipway, I'm not very familiar with network policies, so I'm not sure about some things. In any case, I have a few comments I'd like you to fix.

[maraino]

I don't think the egress for port 80 should be enabled by default, having 443 makes sense, but I would add the list in the values.yaml, including 443 there, and do a range to create the list of ports.

It also makes sense to add to.ipBlock.cidr... as optional to the egress.

[maraino]

On second thought, 80 also makes sense for ACME HTTP-01 challenges, but they both should be configurable from the values.yaml, as you might want to also add UDP 53 for ACME DNS-01 or some other custom thing for OIDC webhooks, ...

[maraino]

Is the DNS resolution affected by this?

[sshipway]

DNS should be fine, as the Kubes already allows DNS resolution to make its way out of the cluster.
Making the ports a list would be possible, but is it really necessary for challenges, which I think are mandated by the ACME standard to be on 80 and 443?
For the egress policy, it makes sense to restrict that to the same subnet(s) as the ingress (as the ones requesting would be the same ones queried). I've added that stanza.

[maraino]

I'm not familiar with networkPolicy, but isn't the targetPolicy enough?

.Values.service.port is used by the ingress (ingress.yaml). I'm unsure if it should be here, as the selector matches the pod. If it is necessary, it should be only there if the ingress is enabled.

[sshipway]

You won't need this if you haven't enabled the ingress and only expect to service acme requests from other containers in the same cluster, but then if that's the case, you're not going to need to enable the Policy at all as that applies to communication outside of the Kubernetes cluster.
So we need to allow the service port inbound if we want hosts outside kubernetes to be able to access acme.

[sshipway]

Ah I see, you think we won't need .Values.service.Port (which is on the ingres and service) because we go in via the .Values.service.targetPort (on the container), or maybe vice-versa? It might be that we can get rid of targetPort if either Service or Ingres are enabled, and get rid of Port if neither are. TBH I'm not 100% certain how kubes works on this, so I opened both to be safe (as its no extra risk if the request bypasses the ingres). If anyone has a definite on this Im happy for guidance?