Using environment variables to update values in worker-spec.yml about dask-kubernetes HOT 11 CLOSED

But I agree with your final point, I'm not particularly concerned about this potential.

from dask-kubernetes.

dask-kubernetes provides two ways to specify the worker template, either as a separate standalone file with a reference to that file in the config, or by placing the entire worker template into the config file. Here is our current blank config file

kubernetes:
  name: "dask-{user}-{uuid}"
  namespace: null
  count:
    start: 0
    max: null
  host: '0.0.0.0'
  port: 0
  env: {}

  worker-template-path: null

  worker-template: {}
    # kind: Pod
    # metadata:
    #   labels:
    #     foo: bar
    #     baz: quux
    # spec:
    #   restartPolicy: Never
    #   containers:
    #   - image: daskdev/dask:latest
    #     args:
    #       - dask-worker
    #       - --nthreads
    #       - '2'
    #       - --no-bokeh
    #       - --memory-limit
    #       - 6GB
    #       - --death-timeout
    #       - '60'
    #     resources:
    #       limits:
    #         cpu: "1.75"
    #         memory: 6G
    #       requests:
    #         cpu: "1.75"
    #         memory: 6G

So one solution would be to just not use worker-spec.yaml, and instead put the worker spec into dask's proper configuration system.

from dask-kubernetes.

We could also merge the two in dask-kubernetes using dask.config.merge(worker_spec_from_file, dask.config.get('kubernetes.worker-template')).

from dask-kubernetes.

Okay, thanks. It seems setting DASK_KUBERNETES__WORKER_TEMPLATE__SPEC__IMAGE along with moving the worker-template to the dask config file will suffice.

Upon further reflection, I'm curious if removing the worker-template file might simplify things here. This would emphasize the use of the dask-config tools which do provide a lot of flexibility.

from dask-kubernetes.

from dask-kubernetes.

Fair enough. I don't have strong feelings here as it seems I can do everything I needed to with existing tooling. Happy to see this closed as is unless others have thoughts on the last topics.

from dask-kubernetes.

So dask/dask#3893 was just merged. How do we feel about expanding environment variables when loading the dask configs from dask-kubernetes?

from dask-kubernetes.

from dask-kubernetes.

I think that one question is "are there any fields that might have environment variables that we *don't *want to expand?"

Not that I'm aware of in this space. @jacobtomlinson, any thoughts here?

from dask-kubernetes.

I'm trying to think of a scenario where this would be a problem.

I guess there is potential for another package to update the environment and then dask to expand something nasty into the config. e.g updating the docker image with a crypto miner.

Personally I wouldn't be concerned about things like this though. If we are worrying about the user executing malicious code I can think of much worse things than this.

from dask-kubernetes.

On the security point, dask is already vulnerable to that sort of environment variable manipulation. The reason we are discussing this is because the image specification in the worker template is in a list of arguments and dask's use of environment variables only works for nested dictionaries.

from dask-kubernetes.