Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

control-service: run data job as non-root user #710

Merged
merged 6 commits into from
Feb 17, 2022

Conversation

antoniivanov
Copy link
Collaborator

Currently data job docker container is run as root user . This is not
considered best practice
(https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user)

And in environment where root is forbidden it won't work. For example
the job would fail if data job kubernetes pod is set to run as specific
user e.g using:

securityContext:
  fsGroup: 1000
  runAsGroup: 1000
  runAsUser: 1000

We are making sure that when building the data job we are setting up
permissions and users and starting the docker container with new user.

The UID and GID can be passed as argument during docker build but that
is not currently exposed to operators when deploying jobs. So the
UID/GID is currently required to be 1000

Testing Done: deployed locally job with runAsUser securityContext (as
above) and the job succeeded. The integration test would verify end to
end as well.

Signed-off-by: Antoni Ivanov aivanov@vmware.com

Currently data job docker container is run as root user . This is not
considered best practice
(https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#user)

And in environment where root is forbidden it won't work. For example
the job would fail if data job kubernetes pod is set to run as specific
user e.g using:

```
securityContext:
  fsGroup: 1000
  runAsGroup: 1000
  runAsUser: 1000
```

We are making sure that when building the data job we are  setting up
permissions and users and starting the docker container with new user.

The UID and GID can be passed as argument during docker build but that
is not currently exposed to operators when deploying jobs. So the
UID/GID is currently required to be 1000

Testing Done: deployed locally job with runAsUser securityContext (as
above) and the job succeeded. The integration test would verify end to
end as well.

Signed-off-by: Antoni Ivanov <aivanov@vmware.com>
@antoniivanov antoniivanov force-pushed the person/aivanov/control-service-build branch from b6caaa4 to 6aa4541 Compare February 16, 2022 22:45
@antoniivanov antoniivanov enabled auto-merge (squash) February 17, 2022 09:54
@antoniivanov antoniivanov merged commit 0ff5930 into main Feb 17, 2022
@antoniivanov antoniivanov deleted the person/aivanov/control-service-build branch February 17, 2022 17:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants