Kubedock does not work with recent testcontainers-java kafka (1.16.+)

[adis-me]

Hi,

First of all: thanks for making and maintaining this repo. Really useful! I have played around with this repo and especially with Kafka testcontainers on OpenShift with Tekton. I found out that your example works nice on OpenShift but mine project failed.

Mainly because your examples use version 1.15.3 while mine project was using 1.16.3. There have been some changes around the dynamic updating of the Kafka config.

With version 1.16.3 the args of the deployed containers look like:

args:
        - sh
        - '-c'
        - |
          #!/bin/bash
          echo 'clientPort=2181' > zookeeper.properties
          echo 'dataDir=/var/lib/zookeeper/data' >> zookeeper.properties
          echo 'dataLogDir=/var/lib/zookeeper/log' >> zookeeper.properties
          zookeeper-server-start zookeeper.properties &
          echo '' > /etc/confluent/docker/ensure 
          /etc/confluent/docker/run 

while 1.15.3 creates:

args:
        - sh
        - '-c'
        - >-
          while [ ! -f /testcontainers_start.sh ]; do sleep 0.1; done;
          /testcontainers_start.sh

[joyrex2001]

It seems to replace and create files that need root permissions, I think this is the reason why it fails in OpenShift (where containers typically are enforced to not run as root).

Related: https://github.com/joyrex2001/kubedock/issues/7

[adis-me]

It seems to replace and create files that need root permissions, I think this is the reason why it fails in OpenShift (where containers typically are enforced to not run as root).

Related: #7

In am not sure how this affects my observation between 1.1.5.x and 1.1.6.x of testcontainers-java. Just to make it clear if I didn't in my previous post: 1.15.3 works well in OpenShift and 1.16.x fails in OpenShift.

[joyrex2001]

By default, OpenShift does not run containers with the root uid/gid, but takes an arbitrary uid instead. This also applies on tekton tasks; they are run as an arbitrary user.

The relation with this issue, and this restricted security context constraint, is that the change on the kafka container implementation in the testcontainers framework wants to write and update files that are owned by uid/gid 0 (root).

Since this is done at runtime, the user that is running the container should have permissions to write to the container should also have permissions to do that. In the (default) OpenShift configuration, this is not the case.

[nekator]

When running vanilla tekton (not openshift-pipelines) on openshift it is nessecary to allow the serviceaccount to run as anyuid. This could be done via oc cli: oc adm policy add-scc-to-user -n <yournamespace> -z <serviceaccount> anyuid

Or via Role and RoleBindings (requires openshift version 4.3.8 or higher):

kind: Role
metadata:
  name: scc-anyuid
  namespace: <yournamespace>
rules:
- apiGroups:
  - security.openshift.io
  resourceNames:
  - anyuid
  resources:
  - securitycontextconstraints
  verbs:
  - use
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: sa-to-scc-anyuid
  namespace: <yournamespace>
subjects:
  - kind: ServiceAccount
    name: <serviceaccount>
roleRef:
  kind: Role
  name: scc-anyuid
  apiGroup: rbac.authorization.k8s.io

[joyrex2001]

Closing in favour of #43.