-
Notifications
You must be signed in to change notification settings - Fork 51
Oracle database should install into a non root k8s container. #74
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
@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. |
@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. |
I don't think that is correct, at not in the release we POCed. Remember to also review init containers. They count as well! 😊 |
@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. |
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/ -- AKS devops, non root container bash-4.2$ cd oradata/ Do you want trace file? |
@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? |
@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. |
Deploying SIDB |
@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 |
Kindly check the PR and revert back if everything is working as expected on your env |
Closing this issue |
Oracle database should install into a non root k8s container.
The text was updated successfully, but these errors were encountered: