WebLogic Kubernetes Operator images starting with version 3.1 and
WebLogic Server images obtained from Oracle Container Registry after August 2020
oracle user with UID 1000 with the default group set to
Here is an excerpt from a standard WebLogic Dockerfile that demonstrates how the file system group ownership is configured in the standard WebLogic Server images:
# Setup filesystem and oracle user # Adjust file permissions, go to /u01 as user 'oracle' to proceed with WLS installation # ------------------------------------------------------------ RUN mkdir -p /u01 && \ chmod 775 /u01 && \ useradd -b /u01 -d /u01/oracle -m -s /bin/bash oracle && \ chown oracle:root /u01 COPY --from=builder --chown=oracle:root /u01 /u01
OpenShift, by default, enforces the
restricted security context constraint which
allocates a high, random UID in the
root group for each container. The standard
images mentioned above are designed to work with the
restricted security context constraint.
However, if you build your own image, have an older version of an image, or obtain an
image from another source, it may not have the necessary permissions. You may need to
configure similar file system permissions to allow your image to work in OpenShift.
Specifically, you need to make sure the following directories have
root as their
group, and that the group read, write and execute permissions are set (enabled):
/u01(or the ultimate parent directory of your Oracle Home and domain if you put them in different locations).
If your OpenShift environment has a different default security context constraint,
you may need to configure OpenShift to allow use of UID 1000 by creating
a security context constraint. Oracle recommends that you define
a custom security context constraint that has just the permissions that are required
and apply that to WebLogic pods. Oracle does not recommend using the built-in
Security Context Constraint, because it provides more permissions
than are needed, and is therefore less secure.
To create a custom security context constraint, create a YAML file with the following
content. This example assumes that your OpenShift project is called
that the service account you will use to run the operator and domains
weblogic-operator. You should change these
users sections to match your environment.
kind: SecurityContextConstraints apiVersion: v1 metadata: name: uid1000 allowHostDirVolumePlugin: false allowHostIPC: false allowHostNetwork: false allowHostPID: false allowHostPorts: false allowPrivilegeEscalation: true allowPrivilegedContainer: false fsGroup: type: MustRunAs groups: - system:serviceaccounts:weblogic readOnlyRootFilesystem: false requiredDropCapabilities: - KILL - MKNOD - SETUID - SETGID runAsUser: type: MustRunAs uid: 1000 seLinuxContext: type: MustRunAs supplementalGroups: type: RunAsAny users: - system:serviceaccount:weblogic:weblogic-operator volumes: - configMap - downwardAPI - emptyDir - persistentVolumeClaim - projected - secret
Assuming you called that file
uid1000.yaml, you can create the security context constraint
using the following command:
$ oc create -f uid1000.yaml
After you have created the security context constraint, you can install the WebLogic Kubernetes Operator.
Make sure you use the same service account to which you granted permission in the security
context constraint (
weblogic-operator in the preceding example). The operator will then run
with UID 1000, and any WebLogic domain it creates will also run with UID 1000.
For additional information about OpenShift requirements and the operator, see OpenShift.
When the user that installs an individual instance of the operator does not have the required privileges to create resources at the Kubernetes cluster level, a dedicated namespace can be used for the operator instance and all the WebLogic domains that it manages. For more details about the
dedicated setting, please refer to Operator Helm configuration values.