search

oracle / oracle-database-operator

The Oracle Database Operator for Kubernetes (a.k.a. OraOperator) helps developers, DBAs, DevOps and GitOps teams reduce the time and complexity of deploying and managing Oracle Databases. It eliminates the dependency on a human operator or administrator for the majority of database operations.
Universal Permissive License v1.0
131 stars 42 forks source link

Oracle database should install into a non root k8s container. #74

Open djjeffr opened 7 months ago

djjeffr commented 7 months ago

Oracle database should install into a non root k8s container.

erikgb commented 5 months ago

@psaini79 adding a comment here, as promised over in https://github.com/oracle/oracle-database-operator/issues/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 commented 5 months ago

@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 commented 5 months ago

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 commented 5 months ago

@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 commented 5 months ago

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 commented 5 months ago

@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 commented 5 months ago

@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 commented 5 months ago

Deploying SIDB

IshaanDesai45 commented 2 weeks ago

@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 commented 2 days ago

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