Oracle database should install into a non root k8s container.

[djjeffr]

Oracle database should install into a non root k8s container.

[erikgb]

@psaini79 adding a comment here, as promised over in #73.

Running containers as the root user is considered a bad practice in Kubernetes. You can find a lot of information on the subject on the Internet, so I won't elaborate more on that here. It is just wrong if you can avoid it.

In a multi-tenant Kubernetes setup, as OpenShift is often used to, this is even more important! Running with elevated permissions should be reserved for cluster system workloads like operators, and should run in well-protected namespaces. OpenShift is "secure by default", which means that in order for a workload to run with any elevated permissions, a proprietary OpenShift resource must be configured and granted to the service account running the workload: Security Context Constraints (SCC).

In general, no SCC should be granted to service accounts in namespaces managed by a standard end-user in a multi-tenant cluster. This implies that any Oracle database workload provisioned by the operator should use exclusively non-root containers. Any container configured to run as root will be blocked from running by OpenShift. So the database will never become functional.

[psaini79]

@erikgb, In general, all the Oracle DB containers in K8s with operator are not running with root user. However, from the operator perspective I will review it and will enforce SSA to make it more secure.

[erikgb]

I don't think that is correct, at not in the release we POCed. Remember to also review init containers. They count as well! 😊

[psaini79]

@erikgb Init containers are helping containers and perform one time activity. Init containers are created using the same image as Oracle DB image and after setting up the env their state turns to completed. Oracle DB image is by default populated with non-root user. However, I will cross verify it to make sure these init containers are not populated with root user.

[djjeffr]

Having problems deploying Oracle to namespace, appears that during deployment to non root container a install script that oracle runs as root fails to change directory permissions correctly. Here is what it looks like on microk8s and AKS: (Note non root container the oracle data directory are still owned by root, should be oracle.

-- microk8s oss5a, root container

sh-4.2$ cd oradata/
sh-4.2$ ls -la
total 8
drwxrwxrwx 4 root root 110 Nov 17 19:23 .
drwxr-xr-x 1 oracle dba 98 Nov 17 19:23 ..
-rw-r--r-- 1 oracle oinstall 0 Nov 17 19:23 .ORACDB.create_lck
-rw-r--r-- 1 oracle oinstall 25 Nov 17 19:23 .ORACDB.created
-rw-r--r-- 1 oracle oinstall 0 Nov 17 20:58 .ORACDB.exist_lck
drwxr-x--- 4 oracle oinstall 4096 Nov 17 19:12 ORACDB
drwxr-xr-x 3 oracle oinstall 20 Nov 17 19:23 dbconfig
sh-4.2$ cd ORACDB/
sh-4.2$ ls -la
total 2479900
drwxr-x--- 4 oracle oinstall 4096 Nov 17 19:12 .
drwxrwxrwx 4 root root 110 Nov 17 19:23 ..
drwxr-x--- 2 oracle oinstall 104 Nov 17 19:23 ORAPDB1
-rw-r----- 1 oracle dba 18726912 Nov 17 21:01 control01.ctl
-rw-r----- 1 oracle dba 18726912 Nov 17 21:01 control02.ctl
drwxr-x--- 2 oracle oinstall 111 Nov 17 19:15 pdbseed
-rw-r----- 1 oracle dba 209715712 Nov 17 19:23 redo01.log
-rw-r----- 1 oracle dba 209715712 Nov 17 21:01 redo02.log
-rw-r----- 1 oracle dba 209715712 Nov 17 19:23 redo03.log
-rw-r----- 1 oracle dba 566239232 Nov 17 21:00 sysaux01.dbf
-rw-r----- 1 oracle dba 933240832 Nov 17 20:59 system01.dbf
-rw-r----- 1 oracle dba 33562624 Nov 17 19:17 temp01.dbf
-rw-r----- 1 oracle dba 367009792 Nov 17 21:01 undotbs01.dbf
-rw-r----- 1 oracle dba 5251072 Nov 17 19:23 users01.dbf
sh-4.2$

-- AKS devops, non root container

bash-4.2$ cd oradata/
bash-4.2$ ls -la
total 8
drwxrwxrwx 2 root oinstall 0 Nov 17 18:43 .
drwxr-xr-x 1 oracle dba 4096 Nov 17 18:50 ..
-rwxrwxrwx 1 root oinstall 0 Nov 17 18:50 .ORACDB.create_lck
-rwxrwxrwx 1 root oinstall 0 Nov 17 20:58 .ORACDB.exist_lck
drwxrwxrwx 2 root oinstall 0 Nov 17 18:45 ORACDB
drwxrwxrwx 2 root oinstall 0 Nov 17 18:50 dbconfig
bash-4.2$ cd ORACDB/
bash-4.2$ ls -la
total 0
drwxrwxrwx 2 root oinstall 0 Nov 17 18:45 .
drwxrwxrwx 2 root oinstall 0 Nov 17 18:43 ..
drwxrwxrwx 2 root oinstall 0 Nov 17 18:45 ORAPDB1
drwxrwxrwx 2 root oinstall 0 Nov 17 18:45 pdbseed
bash-4.2$

Do you want trace file?

[psaini79]

@djjeffr thanks for sharing the details. I do not need trace files at this time. I have a question, this issue occurred with SIDB or sharding controller?

[erikgb]

@psaini79 A good piece of advice is to try running and using the controller on OpenShift. This operator seems to have had some kind of OpenShift certification in the past but appears to have been removed from the list of OpenShift-approved operators. OpenShift will give you nice feedback on violations reported in this issue as it does not allow running as root without adding SCCs.

[djjeffr]

Deploying SIDB

[IshaanDesai45]

@djjeffr in the recent release i.e v1.1.0 we have introduced an additional flag which makes the deployment of the init-permission init container optional. So, you can try with setting setWritePermissions:false to deploy without any elevated permission to the service account

[IshaanDesai45]

Kindly check the PR and revert back if everything is working as expected on your env

[IshaanDesai45]

Closing this issue