Add gcsfuse example to the samples

[sirdarckcat]

the only gcsfuse example was deleted when removing the apache-php sample. https://github.com/google/kctf/blob/57e59756cbe081ff922abc2004a9d168492e4b25/samples/apache-php/challenge.yaml has an example. we should also update the web template with a php and python sample server so people know how to use it.

  podTemplate:
    template:
      spec:
        containers:
        - name: challenge
          volumeMounts:
          - name: sessions
            mountPath: /mnt/disks/sessions
          - name: uploads
            mountPath: /mnt/disks/uploads
        volumes:
        - name: sessions
          persistentVolumeClaim:
            claimName: apache-php-sessions
        - name: uploads
          persistentVolumeClaim:
            claimName: apache-php-uploads
  persistentVolumeClaims:
    - apache-php-sessions
    - apache-php-uploads

[sirdarckcat]

https://docs.google.com/document/d/1zs6p-9P_4hNFxLdAvO5_5ANkG5WpPylFqBajFa8O0gk/edit?usp=drivesdk has a nicer example with just one claim instead of two

spec:
  persistentVolumeClaims:
  - name: apache-php
    size: 21Gi
  podTemplate:
    containers:
    - name: challenge
      volumeMounts:
      - name: apache-php
        subPath: sessions # this this a folder inside volume
        mountPath: /where-to-mount/sessions
      - name: apache-php
        subPath: uploads
        mountPath: /where-to-mount/uploads
    volumes:
    - name: apache-php
      persistentVolumeClaim:
        claimName: apache-php

[sirdarckcat]

Something that might be surprising is that the name of the volume claim must be unique in the namespace, but is mapped to the task. This can cause problems :P

https://github.com/google/kctf/blob/adb03676218aa68c3d86be68d493b847d5bb41b1/kctf-operator/pkg/controller/challenge/volumes/persistentvolume.go#L21

We should probably name the claim ourselves (and add it automatically). I don't think we need more than one claim per task?

[sirdarckcat]

I think we should automatically create a persistentvolumeclaim for every challenge and namespace it to /mnt/gcs/namespace/challengename and name it as the challenge, so remove the per-challenge claim, and then add, by default, a volume to the default pod mounting that under a common name (challenge-persistent or something), but let the user setup the volumeMount themselves only if they need it.

then if a challenge wants to access the volume of another challenge, it can do so just with a volumeMount, and if a challenge wants to create another volumemount, in addition to its own challenge-name one (say, to just have an apache-php-shared I guess? idk) then it can use the current infrastructure, but I don't expect that to be common.

the end result would be, for a normal task:

podTemplate:
    template:
      spec:
        containers:
        - name: challenge
          volumeMounts:
          - name: challenge-persistent
            subPath: sessions
            mountPath: /mnt/disks/sessions
          - name: challenge-persistent
            subPath: uploads
            mountPath: /mnt/disks/uploads

for a task accessing another task volume:

podTemplate:
    template:
      spec:
        containers:
        - name: challenge
          volumeMounts:
          - name: another-task-name
            mountPath: /mnt/disks/another-task-name
      volumes:
      - name: another-task-name
        persistentVolumeClaim:
          claimName: another-task-name

for a "global state" type of volume (eg, for a pubsub type of thing):

podTemplate:
    template:
      spec:
        containers:
        - name: challenge
          volumeMounts:
          - name: global-shared-state-for-task-foo
            mountPath: /mnt/disks/global-shared-state-for-task-foo
      volumes:
      - name: global-shared-state-for-task-foo
        persistentVolumeClaim:
          claimName: global-shared-state-for-task-foo
  persistentVolumeClaims:
    - global-shared-state-for-task-foo

the last one could be done for, for example, have a volume where challenges drop folders with URLs to visit, and an XSS bot visits them and returns the DOM or something.