OpenShift security settings

From Genesys Documentation
Jump to: navigation, search

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.

Early Adopter Program
Genesys Engage cloud private edition is being released to pre-approved customers as part of the Early Adopter Program. Please note that the documentation and the product are subject to change. For more details about the program, please contact your Genesys representative.

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

Setup overview

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

Note:

  • 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.


genesys-restricted.yaml

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