juice-shop / multi-juicer

Host and manage multiple Juice Shop instances for security trainings and Capture The Flags
Apache License 2.0
268 stars 121 forks source link

Isolate JuiceShop Instances from each other using NetworkPolicies #40

Open J12934 opened 4 years ago

J12934 commented 4 years ago

Currently a user could use RCE or SSRF vulnerabilities to connect to JuiceShop instances of other users.

This would kind of be a awesome challenge in itself 😅 Like: "Steal the challenge progress from another team"

But as we (currently 😉) don't have the possibility to add new Challenges at run time it would probably be best to prohibit any traffic coming from JuiceShop to other JuiceShop pods via k8s NetworkPolicies. Might even work to prevent any cluster internal traffic from the JuiceShop this would have to be tested to ensure that this doesn't cause troubles with the juice-balancer.

jonasbg commented 12 months ago

I've tried to isolate the juice-shop running container with the following NetworkPolicy $cat helm/multi-juicer/templates/juice-shop/networkPolicy.yaml

{{- if .Values.juiceShop.networkPolicy }}
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: networkpolicy-juice-shop
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: 'juice-shop'
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
      - podSelector:
          matchLabels:
            app.kubernetes.io/name: 'juice-balancer'
    ports:
    - port: http
  egress:
  - to:
      - podSelector:
          matchLabels:
            app.kubernetes.io/name: 'juice-balancer'
      - podSelector:
          matchLabels:
            app.kubernetes.io/name: 'progress-watchdog'
    ports:
    - port: http
  - ports:
    - port: 53
      protocol: UDP
    - port: 53
      protocol: TCP
    to:
    - namespaceSelector: {}
      podSelector:
        matchLabels:
          k8s-app: kube-dns
{{- end }}

I am missing the same for:

J12934 commented 12 months ago

@jonasbg awesome looks good 🙌

Do you know if the dns egress selector is valid for most k8s clusters? or are there setups where this might fail because the pods don't have the label?

podSelector:
  matchLabels:
    k8s-app: kube-dns

Never maintained network policies for open source helm charts only for specific cluster where i could be very sure about the labels :D

if we can I'd like to also add the net policies to the default helm chart. And have them disableable if somebody doesn't want them (for some reason). Some parts might not be doable (e.g. juice-balancer ingress) as it would come from different namespaces / sources depending on the way it's exposed to the outside of the cluster.

jonasbg commented 11 months ago

I'm not sure if the egress selector for DNS is valid for most k8s clusters unfortunately. I am new to the NetworkPolicy setup, and I don't have that much experienced with it.

I think that this settings should be opt-in from a values.yaml file. Then its possible to gather some feedback on the adoption of it, and it won't brake anything currently deployed.

Suggested format on a values.yaml file:

balancer:
  networkPolicy:
    # -- Optional default value is false.
    enabled: true
...
juice-shop:
  networkPolicy:
    # -- Optional default value is false.
    enabled: true
    # -- Optional Match labels for the Juice Shop NetworkPolicy DNS egress rule.
    dnsMatchLabels:
      k8s-app: kube-dns
      k8s-app: coredns

Perhaps adding a dnsMatchLabels: for DNS queries?