Hi team If I use RawContainer, flytepropeller fails to spawn the pod with the following error.

flytepropeller-7476486c6c-rtkp7 flytepropeller E1002 21:16:23.580394       1 workers.go:102] error syncing 'maps-flyte/a2lmztn5z
v6tt26ddk8k': failed at Node[n0]. RuntimeExecutionError: failed during plugin execution, caused by: failed to execute handle for plugin [container]: [[deny-capabilities] container <a2lmztn5zv6tt26ddk8k-n0-0> has a denied capability. Denied capabilities are ["DAC_READ_SEARCH", "NET_ADMIN", "SYS_ADMIN", "SYS_MODULE", "SYS_PTRACE", "DAC_OVERRIDE", "FOWNER", "KILL", "MKNOD", "NET_BIND_
SERVICE", "NET_RAW", "SETFCAP", "SETGID"]] failed to create resource, caused by: admission webhook "validation.gatekeeper.sh" denied the request: [deny-capabilities] container <a2lmztn5zv6tt26ddk8k-n0-0> has a denied capability. Denied capabilities are ["DAC_READ_SEARCH", "NET_ADMIN", "SYS_ADMIN", "SYS_MODULE", "SYS_PTRACE", "DAC_OVERRIDE", "FOWNER", "KILL", "MKNOD", "NET_BIND_SERV
ICE", "NET_RAW", "SETFCAP", "SETGID"]

Raw containers by default is sys_ptrace capability- which seems to be disabled on your k8s. This can have a security issue. Cc @glamorous-carpet-83516 can they use the file based system

Why is sys_ptrace needed ? Is there a config to disable it ?

the raw containers uses sys_ptrace to communicate with your containers

sorry i m not following the "bit". basically, i want to run a workload which is not python. and i m using flyte to orchestrate it.

@adamant-sandwich-39749 let me try to expand on that (and apologies in advance if you know all of this): • The way flyte runs your workloads is by launching individual K8s Pods, each pod runs a container that know how to download flyte inputs (from s3/gcs/etc.), transform them into the underlying language (python for flytekit or java for flytekit-java) and then transform the outputs back into flyte’s protos and upload them to s3 • If you want to run your own code (no flytekit), you will need a piece of code that knows how to do that.. if you choose raw tasks, the way this will run is it’ll run a flytecopilot-download init container then it’ll run your arbitrary container + flyte-copilot container next to it, the responsibility of the init container is to download the inputs, and make them available for your container, the responsibility of the sidecar flyte-copilot container is to monitor your container to understand if it finished successfully, failed (and its error code)… etc. then make sure flyte propeller (engine running the pod) understands the exit code/logs… etc. • You have a couple of other options if you don’t want the SYS_PTrace capability, you have a few options: ◦ Install flytekit (or flytekit java) into your container. You can create a python function/task that just calls out the shell command you need, and Flytekit will take care of downloading/uploading inputs/outputs… ◦ You can implement flytekit logic on your own (you can be passed in the inputs and output paths and you are expected to use them in a certain way, we unfortunately do not have this protocol documented to point you to) ◦ With copilot you can run in other modes. We can introduce a change in the plugin to allow customizing this behavior (One of the options is to monitor a SUCCESS/FAILURE file that your process would be expected to write) and in this case, the two containers only need to share a disk volume and not a process namespace or require ptrace capability.

Thanks @high-park-82026 for the good explanation. I ll evaluate the option of using flytekit inside my container.