1. Deploying Siebel CRM Containers on Kubernetes using Siebel Cloud Manager
  2. Deploying Siebel CRM on OpenShift using SCM

Deploying Siebel CRM on OpenShift using SCM

This topic describes how to deploy Siebel CRM on OpenShift using the BYOR option using SCM. It includes the following sections:

Before Deploying Siebel CRM on OpenShift

You must apply the required Security Context Constraints (SCCs) before deploying Siebel CRM by using SCM. The SCCs that you apply depend on the security mode that you choose:

  • Enhanced security applies when you specify the security_context section in the Siebel CRM provisioning payload. In this mode, Siebel CRM workloads run with the custom non-root user ID and group ID defined in the payload. You must apply only the SCCs required for workloads that cannot run with the OpenShift restricted-v2 SCC. To apply SCCs for enhanced security:
    1. Create a Siebel CRM namespace. You must ensure that the Siebel CRM namespace matches the value of the env_name parameter specified in the environment provisioning payload.
    2. Create the custom nonroot-builder SCC that allows image build workloads to run with a non-root user while providing the permissions required to build and manage container images. The nonroot-builder SCC is required by the image-builder-sa service account when the image builder runs without privileged mode. A cluster administrator must create this SCC (nonroot-builder-scc.yaml) once per OpenShift cluster:
      allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: true
allowPrivilegedContainer: false
allowedCapabilities: null
apiVersion: security.openshift.io/v1
defaultAddCapabilities: null
fsGroup:
    type: RunAsAny
groups: []
kind: SecurityContextConstraints
metadata:
    name: nonroot-builder
priority: null
readOnlyRootFilesystem: false
requiredDropCapabilities:
- KILL
- MKNOD
runAsUser:
    type: RunAsAny
seLinuxContext:
    type: MustRunAs
supplementalGroups:
    type: RunAsAny
users: []
volumes:
- configMap
- downwardAPI
- emptyDir
- persistentVolumeClaim
- projected
- secret
    3. Apply the SCC as follows:
      oc apply -f nonroot-builder-scc.yaml
      Note: If you deploy Siebel CRM in multiple namespaces, create the nonroot-builder SCC only once at the cluster level. However, you must bind the SCC to the required service accounts in each namespace where Siebel CRM is deployed, as follows: 
      oc -n <siebel_namespace> adm policy add-scc-to-user nonroot-builder -z image-builder-sa
oc -n <siebel_namespace> adm policy add-scc-to-user nonroot-v2 -z image-automation-controller
oc -n <siebel_namespace> adm policy add-scc-to-user nonroot-v2 -z image-reflector-controller
oc -n <siebel_namespace> adm policy add-scc-to-user nonroot-v2 -z notification-controller
oc -n <siebel_namespace> adm policy add-scc-to-user nonroot-v2 -z source-controller
oc -n <siebel_namespace> adm policy add-scc-to-user anyuid -z <siebel_namespace>-metacontroller
oc -n <siebel_namespace> adm policy add-scc-to-user anyuid -z <siebel_namespace>-opensearch
oc -n <siebel_namespace> adm policy add-scc-to-user node-exporter -z node-exporter
oc -n <siebel_namespace> adm policy add-scc-to-user hostmount-anyuid -z node-logs-collector
oc -n <siebel_namespace> adm policy add-scc-to-user anyuid -z siebel-metric-exporter
      Note: Service accounts that are not explicitly granted an SCC use the OpenShift restricted-v2 SCC by default. This SCC provides the least privileged execution model and is the recommended option for workloads that do not require additional permissions.
    4. Review the ingress network policies in the Siebel CRM namespace. You must ensure that the SCM namespace can access the Siebel CRM namespace, and the Siebel CRM namespace can access the SCM namespace.
  • Default security applies when you do not specify the security_context section in the Siebel CRM provisioning payload. In this mode, Siebel CRM workloads run with the default runtime user ID and group ID. You must apply the default SCCs described in this section to the service accounts in the Siebel CRM namespace:
    1. Create a Siebel CRM namespace. You must ensure that the Siebel CRM namespace matches the value of the env_name parameter specified in the environment provisioning payload.
    2. Apply the following SCCs to the service accounts in the Siebel CRM namespace:
      oc adm policy add-scc-to-user nonroot-v2 -z image-automation-controller -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z image-reflector-controller -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z notification-controller -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z source-controller -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z <siebel_namespace>-traefik -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z list-svc-sa -n <siebel_namespace>
oc adm policy add-scc-to-user privileged -z list-svc-sa -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z get-and-create-configmaps -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z ses-sa -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z sai-sa -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z smc-sa -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z cgw-sa -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z connectivity-sa -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z sfs-sa -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z persistence-cleanup-sa -n <siebel_namespace>
oc adm policy add-scc-to-user anyuid -z image-builder-sa -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z prometheus-adapter -n <siebel_namespace>
oc adm policy add-scc-to-user anyuid -z prometheus -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z prometheus-alertmanager -n <siebel_namespace>
oc adm policy add-scc-to-user anyuid -z siebel-metric-exporter -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z kube-state-metrics -n <siebel_namespace>
oc adm policy add-scc-to-user node-exporter -z node-exporter -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z oracle-db-monitoring -n <siebel_namespace> 
oc adm policy add-scc-to-user anyuid -z <siebel_namespace>-opensearch -n <siebel_namespace>
oc adm policy add-scc-to-user nonroot-v2 -z <siebel_namespace>-opensearch-dashboards -n <siebel_namespace>  
oc adm policy add-scc-to-user nonroot-v2 -z log-aggregator -n <siebel_namespace>
oc adm policy add-scc-to-user hostmount-anyuid -z node-logs-collector -n <siebel_namespace>

      In the above example, <siebel_namespace> is the name of the Siebel CRM namespace you created in the previous step.

    3. Review the ingress network policies in the Siebel CRM namespace. You must ensure that the SCM namespace can access the Siebel CRM namespace, and the Siebel CRM namespace can access the SCM namespace.
Note: Oracle recommends adopting the enhanced security model with custom non-root user ID and group ID at the earliest opportunity. This approach provides improved security and aligns with future platform requirements. Support for the default security model is planned to be withdrawn in a future release.

Configuring Siebel File System Directories for a Custom Non-Root User

Before you deploy Siebel CRM on OpenShift with a custom non-root user ID, you must mount the Siebel File System on a host that can access the mount target. You must mount both the Siebel File System export path and the migration export path. This lets you create the required base directories and set the correct ownership.

To configure Siebel File System directories for a custom non-root user:

  1. Mount the Siebel File System export path:
    sudo mount -t nfs -o nfsvers=3,nosuid,resvport -o nolock <mount_target_ip>:/<sfs_export_path> <path_on_your_host_to_mount_sfs>
  2. Mount the migration export path:
    sudo mount -t nfs -o nfsvers=3,nosuid,resvport -o nolock <mount_target_ip>:/<migration_export_path> <path_on_your_host_to_mount_migration>
  3. Create the base directory for the Siebel File System as follows:
    cd <path_on_your_host_to_mount_sfs>
sudo mkdir -p <SIEBEL_NAMESPACE>/FS
sudo chown -R <runAsUser_value>:0 <SIEBEL_NAMESPACE>
sudo chmod -R g+rwx <SIEBEL_NAMESPACE>
  4. Create the base directory for the migration file system as follows:
    cd <path_on_your_host_to_mount_migration>
sudo mkdir -p migration
sudo chown -R <runAsUser_value>:0 migration
sudo chmod -R g+rwx migration

In the examples above:

  • <SIEBEL_NAMESPACE> is the Siebel CRM namespace name in uppercase.
  • <runAsUser_value> is the value specified in siebel.security_context.run_as_user in the Siebel CRM provisioning payload. If siebel.security_context is not specified, use 1000.
Note: If you use multiple Siebel File Systems or migration file systems, repeat this procedure for each file system.

Deploying Siebel CRM using SCM

You can deploy Siebel CRM on OpenShift by following the same procedure you use to deploy Siebel CRM on a Kubernetes cluster. However, OpenShift deployments require the BYO namespace option.

In the environment provisioning payload:

  • Set the byo_ns parameter to true to use the BYO namespace option.
  • Set kubernetes_type to BYO_OPENSHIFT.
  • Provide the OpenShift cluster kubeconfig path in the byo_openshift section.

Siebel CRM is deployed into the namespace that you create and manage.

When deploying Siebel CRM on OpenShift, you can optionally specify a custom security context in the environment provisioning payload. This configuration allows Siebel CRM and observability workloads to run with user and group IDs that are permitted by the OpenShift namespace.

To configure a custom security context in the environment provisioning payload, add the security_context section under:

  • The siebel section to configure Siebel CRM workloads.
  • The observability section to configure observability workloads, if observability is enabled.

When a custom security context is configured, the deployed workloads run with the specified user and group IDs instead of the default runtime IDs. Ensure that the configured values are allowed by the OpenShift namespace security policies.

Sample security_context section:

{
    "siebel": {
        "security_context": {
            "run_as_user": <uid>,
            "run_as_group": <gid>,
            "fs_group": <fs_group_id>
        }
    },
    "infrastructure": {
        "kubernetes": {
            "kubernetes_type": "BYO_OPENSHIFT",
            "byo_openshift": {
                "kubeconfig_path": "/home/opc/siebel/kubeconfig.yaml",
                "byo_ns": true
            }
        }
    },
    "observability": {
        "security_context": {
            "run_as_user": <uid>,
            "run_as_group": <gid>,
            "fs_group": <fs_group_id>
        }
    }
}
Note:
  • If you specify security_context, you must configure the following parameters: run_as_user, run_as_group, and fs_group.
  • On OpenShift, run_as_user must be within the range specified by the openshift.io/sa.scc.uid-range namespace annotation. The fs_group value must be the first ID in the range specified by the openshift.io/sa.scc.supplemental-groups namespace annotation. To view these namespace annotations, execute the following command:
    oc get namespace <siebel_namespace> -o jsonpath='{"openshift.io/sa.scc.uid-range\t"}{.metadata.annotations.openshift\.io/sa\.scc\.uid-range}{"\n"}{"openshift.io/sa.scc.supplemental-groups\t"}{.metadata.annotations.openshift\.io/sa\.scc\.supplemental-groups}{"\n"}'

    You must use a value from the uid-range annotation for run_as_user. Use the first ID from the supplemental-groups annotation for fs_group.

For more information, see Deploying Siebel CRM using SCM and Notes on BYO Namespace.

For more information about the payload parameters, see Payload Parameters for Siebel CRM Deployment.

After Siebel CRM is deployed on OpenShift, you can install Siebel monthly updates by following the procedure described in Installing Siebel Monthly Updates in a Siebel CRM Environment Deployed by SCM.