Context: We are running kubernetes (microk8s) on an ubuntu 18.04 for a student project. We have a dotnet app that is trying to access a mongodb pod. This all goes well. The problem starts when we try to backup the mongodb pd via binding the /data/db folder in the pod to a folder located on the server via volumes and hostPath. Our deployment file is visible here:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend-api-mongo-dep
  labels:
    app: frontend-api-mongo
  namespace: backend
spec:
  replicas: 1
  selector:
    matchLabels:
      app: frontend-api-mongo
  template:
    metadata:
      labels:
        app: frontend-api-mongo
    spec:
      securityContext:
        runAsUser: 1000
        runAsGroup: 3000
        fsGroup: 2000
      containers:
      - name: mongo
        image: mongo:latest
        ports:
        - containerPort: 27017
        command:
          - mongod
          - "--bind_ip_all"
        volumeMounts:
          - mountPath: /data/db
            name: frontend-api-data
        securityContext:
          allowPrivilegeEscalation: false
      volumes:
        - name: frontend-api-data
          hostPath:
            path: /mnt/k8s/mongo
            type: Directory

This is however giving us problems because by default our CICD system (jenkins) can't access the files since these are created as root. To avoid this we added the securityContext to our deployment file and this creates the files with the right permissions. But after changing these we can't use 'kubctl exec' and 'kubectl cp' anymore on these pods since these commands give us these errors:

error: Internal error occurred: error executing command in container: failed to exec in container: failed to start exec "f99b5478a4d6107d83d9d03125a5fcd70b1dd9a9cce09d15d8ace976c493c757": OCI runtime exec failed: exec failed: container_linux.go:345: starting container process caused "apparmor failed to apply profile: write /proc/self/attr/exec: operation not permitted": unknown

We think this is caused by the pod expecting the user to be root and therefore be able to write to certain files within the pod. We hoped we could avoid this by removing the runAsUser/runAsGroup lines and only keep the fsGroup in the securityContext but that gives the same error. Removing the allowPrivilegeEscalation also doesn't fix the issue since the container then creates files as root again.

Is there a way to fix this problem, or are we using the securityContext in the wrong way?