Add support for RUN --network=none --security=insecure

[rhatdan]

Docker now supports --network and --security option on the RUN line in Dockerfiles, this PR adds support for both.

Signed-off-by: Daniel J Walsh [email protected]

[openshift-ci[bot]]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: rhatdan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• ~~OWNERS~~ [rhatdan]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[rhatdan]

@flouthoc @nalind PTAL

[openshift-ci[bot]]

@rhatdan: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

[nalind]

The dockerclient implementation needs to complain about features it doesn't support.

[rhatdan]

@nalind not sure where that happens?

[nalind]

dockerclient.ClientExecutor.Run(). Places where we've neglected this before produced #187, which was a bad experience for users who run the imagebuilder binary.

[rhatdan]

@flouthoc Please take this over. I am not going to have time to complete it

[nalind]

I would also suggest dropping --security. It's a "labs" feature in BuildKit, and not enabled there by default (compared to the current version of this PR, which makes it available all the time), and we don't have an identified use case for it. What's the benefit to imagebuilder?

[rhatdan]

The only use case would be if you wanted to run a --privileged container from within a build. But I am fine with dropping it.

[flouthoc]

I'm taking over this PR and will create two different PR for RUN --network and RUN --security

[nalind]

I would again suggest dropping --security.

[flouthoc]

I would again suggest dropping --security.

@nalind Ackd dropping this for now.

[nalind]

What are the use case and argument for overriding the specified or default value of the --network CLI setting from inside of a Dockerfile? BuildKit at least requires that the user decide to allow these things at build-time, and I don't see any such precaution in here.

[flouthoc]

What are the use case and argument for overriding the specified or default value of the --network CLI setting from inside of a Dockerfile? BuildKit at least requires that the user decide to allow these things at build-time, and I don't see any such precaution in here.

I haven't check the current PR's implementation yet but I'd assume that RUN --network should only override for a specific RUN invocation and not for the entire build. So for instance a build can be invoked with CLI --network=host but certain RUN instructions can be isolated with RUN --network=none <some task>

Maybe something like: https://github.com/moby/buildkit/blob/master/frontend/dockerfile/docs/reference.md#example-isolating-external-effects

[rhatdan]

Yes that is what I would expect.

[rhatdan]

When I originally looked at this, it looked like imagebuilder and buildah were setup to allow the override on a per RUN bases.

I guess if you were overly cautious you might have

RUN dnf -y update ... RUN --network=none /run/local/script