run platform containers as non-root users

[jrhizor]

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

[martimors]

Currently blocked by this! Would be awesome to be able to run it as non-root (openshift requires it).

[martimors]

@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?

[alafanechere]

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?

[davinchia]

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?

[martimors]

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
• Default uid/gid is 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 default

Detailed 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?

podsecuritypolicy.yaml

```yaml apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: 90-ephemeral annotations: seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default' apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' seccomp.security.alpha.kubernetes.io/defaultProfileName: 'runtime/default' apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' spec: privileged: false # Required to prevent escalations to root. allowPrivilegeEscalation: false # This is redundant with non-root + disallow privilege escalation, # but we can provide it for defense in depth. requiredDropCapabilities: - ALL # Allow core volume types. volumes: - 'configMap' - 'emptyDir' - 'projected' - 'secret' - 'downwardAPI' hostNetwork: false hostIPC: false hostPID: false runAsUser: # Require the container to run without root privileges. rule: 'MustRunAs' # Generally, ranges can be found by browsing doing `egrep '?ID_(MIN|MAX)' /etc/login.defs` ranges: # Forbid adding the root group. - min: 1000 max: 65536 - min: 2 max: 65536 seLinux: # This policy assumes the nodes are using AppArmor rather than SELinux. rule: 'RunAsAny' supplementalGroups: rule: 'MustRunAs' ranges: # Forbid adding the root group. - min: 1000 max: 65536 - min: 2 max: 65536 fsGroup: rule: 'MustRunAs' ranges: # Forbid adding the root group. - min: 1000 max: 65536 - min: 2 max: 65536 readOnlyRootFilesystem: false ```

[martimors]

~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!

[davinchia]

@natikgadzhi @perangel I believe this is done. Can we close this?

[davinchia]

This is supported as of version 0.57.