search

appsody / stacks

Appsody application stacks. This repo will be archived soon.
https://appsody.dev
Apache License 2.0
90 stars 120 forks source link

Update quarkus Dockerfile to run as non-root #720

Closed arthurdm closed 4 years ago

arthurdm commented 4 years ago

In the dev image quarkus runs with uid=1001(quarkus) gid=1001(quarkus) groups=1001(quarkus), but in the final production image it is running with uid=0(root) gid=0(root) groups=0(root).

This issue is a request to update the final production Dockerfile to run as uid 1001. With this change, the final production image could pass the Red Hat certification criteria. This is not required for Appsody, but it would be great if we could get this up to par with Open Liberty (with is already using uid 1001 gid 0).

arthurdm commented 4 years ago

fyi @paulrobinson - with this change we could potentially use the same Quarkus stack for both Appsody and Kabanero/CP4Apps.

paulrobinson commented 4 years ago

Hi @arthurdm. Do you have an example of this being done for another stack that passes the RH criteria (with UBI minimal as the base image)?

I want to make sure I'm following the right approach. At the moment I think I need to use microdnf to install shadow-utils to give me the adduser command.

arthurdm commented 4 years ago

hey @paulrobinson - the Open Liberty Dockerfile uses the UBI 8 standard image (not the min image, for serviceability reasons that we ran into using min).

Here's an example from an IBM Java image that uses the pattern you described.

sam-github commented 4 years ago

I thought the cert requirement was to be able to run as an abitrary user-id, not just a non-root user?

arthurdm commented 4 years ago

That's a good point @sam-github - the "arbitrary ID" part is fulfilled by ensuring that all files have group permissions for gid 0.

@paulrobinson - in OpenShift a random non-root ID is used, so you have to make sure that the files Quarkus needs to read/write/execute have the correct permissions at the group level (gid 0).

paulrobinson commented 4 years ago

FYI: @arthurdm I've not forgotten about this. I've been focused on getting https://github.com/appsody/stacks/pull/702 merged, which should be done before this anyway.

paulrobinson commented 4 years ago

@arthurdm and @sam-github Can you take a look at https://github.com/appsody/stacks/pull/778 please?

I think I've one what's needed. But in particular, I'm not confident that I've set the group permissions correctly to support OpenShift's random non-root ID.

arthurdm commented 4 years ago

thanks @paulrobinson - that looks correct to me. Is /work the only directory that Quarkus needs during runtime? One of the things you can do locally in your machine to simulate OpenShift's usage is to run with another ID (i.e. like -u 1002).

neeraj-laad commented 4 years ago

As we are creating a new user, I would prefer to create a named user (quarkus) rather than using a uid=1001. We are then not relying on behaviour based on matching a local user with uid 1001 etc.

@arthurdm @sam-github @scottkurz @paulrobinson Is there a best practice recommendation to have hardcoded uid values vs user names?

arthurdm commented 4 years ago

hey @neeraj-laad - the PR is creating a user named quarkus and assigning an uid of 1001. So then afterwards it's using quarkus for the ownership.

I recall at some point there were commands that required uid vs user names, but perhaps that's been all fixed now. Either way, it seems the PR conforms to what's been asked?