OpenShift security settings
- 1 The genesys-restricted SCC
- 2 Creating and configuring the genesys-restricted SCC
- 3 Associating the genesys-restricted SCC with a specific service
- 4 Detailed contents of the genesys-restricted SCC
- 5 Sample output from the Create SCC command
Learn how to use OpenShift security context constraints (SCCs) to control pod permissions in the OpenShift environment. For general information on private edition security, see the security overview.
Genesys uses security context constraints (SCCs) to control pod permissions in the OpenShift environment. The goal is to provide an appropriate set of permissions that are limited—as much as possible, anyway—to a select group of users responsible for deploying and managing the private edition software. This is essentially a form of role-based access control (RBAC).
OpenShift comes with eight predefined SCCs with varying levels of access control. By default, all pods and containers in the private edition environment use the restricted SCC, which is the most restrictive of these predefined SCCs.
However, Genesys has created a customized SCC—based on the restricted SCC, but differing from it in ways that are explained below—in order to better meet the security requirements of Genesys Engage cloud private edition. The genesys-restricted SCC has been created in compliance with OpenShift best practices for cluster role management and deployment.
Note: In order to preserve customized SCCs during upgrades, do not edit settings on the default SCCs.
The genesys-restricted SCC
The genesys-restricted SCC is based on the default restricted SCC. However, it varies from that SCC in the following ways:
- Access is linked specifically to user genesys and to the group called genesys-restricted-group
- This SCC expands volume types to allow pods to work with varying infrastructure needs
- Rather than using the default behavior of arbitrary user IDs, genesys-restricted allows containers to specify the user and ID, for example, genesys/500. Note that the Genesys Engage containers have been deployed to conform to this behavior.
- This SCC does not allow for privilege escalation, but does allow for predictable user and ID
Use these basic steps to create and configure the genesys-restricted SCC, as described in further detail below:
- Create the custom SCC
- Create a ClusterRole to use the SCC
- Assign the ClusterRole to the appropriate user group
Creating and configuring the genesys-restricted SCC
- The following steps require ClusterAdmin privileges.
- You must carry out these steps before you deploy any Genesys Engage services.
Create the custom SCC
Note: Before you run this command, examine the detailed YAML file included below, making sure to take note of the changes you must make to prepare the file for use in your own environment.
$ oc create -f genesys-restricted.yaml
Create a ClusterRole to use the SCC
$ oc create clusterrole genesys-restricted-scc --verb=use --resource=securitycontextconstraints.security.openshift.io --resource-name=genesys-restricted
Assign the ClusterRole to the appropriate user group
$ oc adm policy add-cluster-role-to-group genesys-restricted-scc genesys-restricted-group
Associating the genesys-restricted SCC with a specific service
Once you have created and configured the genesys-restricted SCC, you must execute the following command for each service before you deploy that service.
Note that the following sample command does not specify either the exact service name or the exact namespace information. The specific command for each service is provided in the service deployment guide for that service.
$ oc adm policy add-scc-to-user genesys-restricted -z <serviceAccount> -n <namespace>
Detailed contents of the genesys-restricted SCC
Here is a listing of the default YAML file for genesys-restricted.
Note: When you create a version of this file for use in your own environment, you must update all of the appropriate volume names to correspond to the objects that your cluster uses. These names are dependent upon your target deployment platform.
kind: SecurityContextConstraints metadata: name: genesys-restricted allowHostDirVolumePlugin: false allowHostIPC: false allowHostNetwork: false allowHostPID: false allowHostPorts: false allowPrivilegeEscalation: true allowPrivilegedContainer: false allowedCapabilities: null apiVersion: security.openshift.io/v1 defaultAddCapabilities: null fsGroup: ranges: - max: 65535 min: 500 type: MustRunAs groups: - genesys-restricted-group priority: null readOnlyRootFilesystem: false requiredDropCapabilities: - KILL - MKNOD - SETUID - SETGID runAsUser: type: MustRunAsRange uidRangeMax: 65535 uidRangeMin: 500 seLinuxContext: type: MustRunAs supplementalGroups: ranges: - max: 65535 min: 500 type: MustRunAs users: - genesys volumes: - configMap - downwardAPI - emptyDir - persistentVolumeClaim - projected - secret - <infrastructure volume type 1, e.g. azureFile> - <infrastructure volume type 2, e.g. azureDisk>
Sample output from the Create SCC command
Here is sample output from the Create SCC command:
Name: genesys-restricted Access: Users: genesys Groups: genesys-restricted-group Settings: Allowed Volume Types: configMap,downwardAPI,emptyDir,persistentVolumeClaim,projected,secret, <infrastructure volume type 1, e.g. azureFile>, <infrastructure volume type 2, e.g. azureDisk> Run As User Strategy: MustRunAsRange UID: <none> UID Range Min: 500 UID Range Max: 65535 FSGroup Strategy: MustRunAs Ranges: 500-65535 Supplemental Groups Strategy: MustRunAs Ranges: 500-65535