Closed jrhizor closed 1 week ago
Currently blocked by this! Would be awesome to be able to run it as non-root (openshift requires it).
@alafanechere I see there's a history here. I could potentially contribute to making this happen, but would like some feedback from the core team first. Is this a good community issue? I see that the previous attempt failed because of some failing acceptance tests, how do we make sure that doesn't happen again? Is it just a matter of picking up that previously merged and reverted PR and adding the missing containers such as bootloader?
Hey @davinchia, could you please let us know if @dingobar's initiative could overlap with works from your team? Do you have any point of attention to share to suggest @dingobar the right direction?
I don't believe anyone is working on this from the Airbyte side. I'd have to do some more research before I can comment. @dingobar can I see an example Kube config your openshift cluster runs today?
Hi! Sorry for taking so long to get back to this, I was caught in something else. First of all, turns out we are not running OpenShift, but rather basing our container security around the one of OpenShift - sorry for misleading. When it comes to privileges, pods have to satisfy these requriements to be scheduled on our cluster:
privileged=false
and allowPrivilegeEscalation=false
runAsUser
in the range {2, 65536}
runAsGroup
in the range {2, 65536}
as well as fsGroup
1000
, which is a common UID for many containers because linux sometimes very vaguely suggests that < 1000 is reserved for system, I've also seen 65536
(nobody
or nogroup
) used as defaultDetailed PodSecurityPolicy
below.
I think, from a security perspective, these restrictions are a reasonable minimum, and in fact quite permissive as in the end all that matters is that the container user cannot pretend to be root on the node host. Airbyte calls out to a lot of different places around the internet, so I'd argue that we should not take security lightly given the amount of IO going on here.
Hope that answers your question. As mentioned, I don't mind taking a stab at this, but I may need some assistance at some point to get the tests running properly as well as potentially adding some new ones to assert that the containers don't start as root by default. Where do we proceed from here?
~Hi again! Sorry for the spam, but I've got some time to spend on this in the near future. I have a suggestion how to proceed:~ ~- Create a test that checks if the container is root when starting up~ ~- Make one of the containers (probably the server component?) run as non-root and run the entire test-suite against it~ ~- PR + feedback on the approach~
We ended up using Meltano for now. Still would like to see this be fixed in case we revisit this!
@natikgadzhi @perangel I believe this is done. Can we close this?
This is supported as of version 0.57.
The context (and most of the implementation) is laid out in https://github.com/airbytehq/airbyte/pull/7872
Creating an issue here to make sure we actually do this instead of letting a merging PR like https://github.com/airbytehq/airbyte/pull/8612 to fester indefinitely.
Not super urgent but it might be a good early project for someone to get familiar with the different parts of the system, our Docker builds, and how we test and release changes like this to OSS.
┆Issue is synchronized with this Monday item by Unito