Skip to content

Add optional network policy object for deploy of step-certificates #172

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
sshipway wants to merge 2 commits into
base: master
Choose a base branch
from
+60 −1
Open

Add optional network policy object for deploy of step-certificates #172

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a1b637e
Add optional network policy object for deploy of step-certificates
sshipway Jan 18, 2024
10f4406
Update to further restrict egress rule
sshipway Jan 30, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions step-certificates/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -302,6 +302,9 @@ chart and their default values.
| `existingSecrets.certsAsSecret` | When `true`use existing secret for certs instead of ConfigMap | `false` |
| `existingSecrets.configAsSecret` | When `true`use existing secret for configuration instead of ConfigMap | `false` |
| `podSecurityContext` | Set SecurityContext on POD level for STEP CA and STEP CA bootstrap job | See [values.yaml](./values.yaml) |
| `networkpolicy.enabled` | When `true` create the NetworkPolicy definition | `false` |
| `networkpolicy.annotations` | Additional annotations to add to the NetworkPolicy definition | `{}` |
| `networkpolicy.allow` | If defined, restrict policy allow rule to only these CIDR subnets | `[]` |

Specify each parameter using the `--set key=value[,key=value]` argument to `helm
install`. For example,
Expand Down
39 changes: 39 additions & 0 deletions step-certificates/templates/policy.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
{{- if .Values.networkpolicy.enabled -}}
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: {{ include "step-certificates.fullname" . }}-policy
namespace: {{ .Release.Namespace }}
labels:
{{- include "step-certificates.labels" . | nindent 4 }}
{{- with .Values.networkpolicy.annotations }}
annotations:
{{- toYaml . | nindent 4 }}
{{- end }}
spec:
podSelector:
Comment thread
sshipway marked this conversation as resolved.
Outdated
matchLabels:
app.kubernetes.io/name: {{ include "step-certificates.name" . }}
policyTypes:
- Ingress
- Egress
ingress:
- ports:
- protocol: TCP
port: {{ .Values.service.targetPort }}
- protocol: TCP
port: {{ .Values.service.port }}
Comment on lines +24 to +25

@maraino maraino Jan 19, 2024

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 sshipway Jan 30, 2024

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 sshipway Jan 30, 2024

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

{{- if .Values.networkpolicy.allow }}
from:
{{- range .Values.networkpolicy.allow }}
- ipBlock:
cidr: {{ . | quote }}
{{- end }}
{{- end }}
egress:
- ports:
- protocol: TCP
port: 443
- protocol: TCP
port: 80
Comment on lines +33 to +38

@maraino maraino Jan 19, 2024

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 maraino Jan 19, 2024

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 maraino Jan 19, 2024

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is the DNS resolution affected by this?

@sshipway sshipway Jan 30, 2024

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

{{- end }}
12 changes: 11 additions & 1 deletion step-certificates/values.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,4 @@
---
# Default values for step-certificates.

# kind is the type of object to use when deploying the CA.
Expand Down Expand Up @@ -278,7 +279,7 @@ ca:
# existingClaim: ""
# accessModes defines the Persistent Volume Access Mode.
accessModes:
- ReadWriteOnce
- ReadWriteOnce
# size is the Persistent Volume size.
size: 10Gi
# Whether to enable ssh support for step-ca
Expand Down Expand Up @@ -387,3 +388,12 @@ podSecurityContext:
fsGroup: 1000
# seccompProfile:
# type: RuntimeDefault

# Set up a network policy to allow incoming connections to the service
# This is useful if your cluster has a default:deny policy set
networkpolicy:
enabled: false
annotations: {}
# Subnets to allow incoming access in CIDR format (eg: "10.0.0.0/8")
# If not defined, allow all
# allow: []