Difference between revisions of "PrivateEdition/Current/PEGuide/Prerequisites"

From Genesys Documentation
Jump to: navigation, search
(Published)
(Published)
Line 17: Line 17:
 
*Web Application Firewall (WAF) - optional, but recommended.
 
*Web Application Firewall (WAF) - optional, but recommended.
  
<nowiki>**</nowiki>''Currently, Genesys supports OpenShift Container Platform 4.6 and 4.7 as part of the cloud private edition offering. If you are looking for other Kubernetes offerings, contact your Genesys Account Representative.''
+
<nowiki>**</nowiki>''Currently, Genesys supports OpenShift Container Platform 4.6 as part of the cloud private edition offering. If you are looking for other Kubernetes offerings, contact your Genesys Account Representative.''
 
|Status=No
 
|Status=No
 
}}{{Section
 
}}{{Section
Line 37: Line 37:
 
|sectionHeading=Permissions
 
|sectionHeading=Permissions
 
|alignment=Vertical
 
|alignment=Vertical
|structuredtext=OpenShift controls the pod permissions (including user access) through a security feature called ''security context constraints'' (SCCs). Genesys has created a customized SCC called '''''genesys-restricted SCC''''' which covers the user access as one of the constraints. See {{Link-SomewhereInThisVersion|manual=PEGuide|topic=ConfigSecurity}} for a detailed procedure.
+
|structuredtext=Security context parameters in the Helm charts specify the users authorized to access the pods and containers for the respective services. By default, the Helm charts specify the user, group, and file-service group IDs as <tt>500:500:500</tt>.
 +
 
 +
===OpenShift===
 +
OpenShift controls the pod permissions (including user access) through a security feature called ''security context constraints'' (SCCs). Private edition supports the use of arbitrary user IDs (UIDs), with pods and containers using the '''restricted''' SCC (the most restrictive SCC defined by default).
 +
 
 +
In an early implementation, private edition required the use of a custom SCC called '''genesys-restricted''' to control permissions associated with the '''genesys''' user (500) specified by the services. The '''genesys-restricted''' SCC has now been deprecated. 
 +
 
 +
====Arbitrary UIDs====
 +
To use arbitrary UIDs, override the Helm chart values so that no specific IDs are defined for users and groups. See {{Link-SomewhereInThisVersion|manual=PEGuide|topic=ConfigSecurity}} for more information.
  
*If you are a Cluster Administrator, create a cluster role, create a user group called '''genesys-restricted-group,''' assign the cluster role to the user group, and then add users to the group. These users have appropriate permissions to manage Genesys Engage services.
 
*If you are deploying Genesys Engage services, make sure that your user ID is part of the '''genesys-restricted-group''' group. To add your user ID to '''genesys-restricted-group''', contact your Cluster Administrator.
 
 
|Status=No
 
|Status=No
 
}}
 
}}
 
}}
 
}}

Revision as of 19:59, September 14, 2021

Prerequisite software and third-party dependencies required for the Genesys Engage cloud private edition environment.

Prerequisites

This article describes the prerequisites and third-party infrastructure services (dependencies) you must deploy before deploying Genesys Engage services.

  • Domain Name System (DNS)
  • Helm 3.0+
  • Ingress Controller
  • JFrog Edge Artifactory account
  • Kubernetes 1.18.x - 1.19.x **
  • Session Border Controller (SBC)
  • Web Application Firewall (WAF) - optional, but recommended.

**Currently, Genesys supports OpenShift Container Platform 4.6 as part of the cloud private edition offering. If you are looking for other Kubernetes offerings, contact your Genesys Account Representative.

Third-party dependencies

Genesys Engage services require specific third-party back-end services as an infrastructure prerequisite. You can install these third-party infrastructure prerequisites in a different namespace or outside the cluster provided the namespace has direct network access to these services.
Important
Deploying and maintaining the third-party dependencies is your responsibility. For more information on your responsibilities and how Genesys supports the deployment process, see [[PrivateEdition/Current/PEGuide/GenesysVsCustomer|]].

See the table below for details about the prerequisite third-party dependencies.

Genesys has tested the OpenShift Operators listed in the table, but you can check with Genesys regarding replacing them with other cloud managed services (such as, Azure Postgres or AWS RDS Postgres). You could also run these services outside of OpenShift if you prefer.

Name Version OpenShift Operator Hub OpenShift Operator URL Purpose
A container image registry and Helm chart repository Used for downloading Genesys containers and Helm charts into the customer's repository to support a CI/CD pipeline. You can use any Docker OCI compliant registry.
An SMTP relay Facilitates email communications in an environment where GCXI reports or voicemails are sent as emails to contact center personnel. Genesys recommends PostFix, but you can use any SMTP relay that supports standard mail libraries.
Command Line Interface OpenShift CLI (oc) https://cloud.redhat.com/products/container-platform The command line interface tools to log in and work with the Kubernetes clusters.
HTTPS certificates - cert-manager Use with Let's Encrypt to provide free rotating TLS certificates for NGINX Ingress Controller.
HTTPS certificates - Let's Encrypt Use with cert-manager to provide free rotating TLS certificates for NGINX Ingress Controller. Note: Let's Encrypt is a suite-wide requirement if you choose an Ingress Controller that needs it.
Ingress controller Ingress Operator https://docs.openshift.com/container-platform/4.8/networking/ingress-operator.html HTTPS ingress controller.
Load balancer VPC ingress. For NGINX Ingress Controller, a single regional Google external network LB with a static IP and wildcard DNS entry will pass HTTPS traffic to NGINX Ingress Controller which will terminate SSL traffic and will be setup as part of the platform setup.
Object storage Persistent or shared data storage, such as Amazon S3, Azure Blob Storage, or Google Cloud Storage.
Kafka 2.x Banzai Cloud Kafka Operator https://operatorhub.io/operator/banzaicloud-kafka-operator Message bus.
Keda 2.0 KEDA Operator https://operatorhub.io/operator/keda Custom metrics for scaling. Use of Keda or HPA is configurable through Helm charts.
Redis 6.x Redis Enterprise Operator https://operatorhub.io/operator/redis-enterprise Used for caching. Only distributions of Redis that support Redis cluster mode are supported, however, some services may not support cluster mode.
Consul 1.13.x Service discovery, service mesh, and key/value store.
Elasticsearch 7.x Elasticsearch (ECK) Operator https://operatorhub.io/operator/elastic-cloud-eck Used for text searching and indexing. Deployed per service that needs Elasticsearch during runtime.
MS SQL Server 2016 or later Relational database. Required only for GVP.
PostgreSQL 11.x Relational database.

Permissions

Security context parameters in the Helm charts specify the users authorized to access the pods and containers for the respective services. By default, the Helm charts specify the user, group, and file-service group IDs as 500:500:500.

OpenShift

OpenShift controls the pod permissions (including user access) through a security feature called security context constraints (SCCs). Private edition supports the use of arbitrary user IDs (UIDs), with pods and containers using the restricted SCC (the most restrictive SCC defined by default).

In an early implementation, private edition required the use of a custom SCC called genesys-restricted to control permissions associated with the genesys user (500) specified by the services. The genesys-restricted SCC has now been deprecated.

Arbitrary UIDs

To use arbitrary UIDs, override the Helm chart values so that no specific IDs are defined for users and groups. See OpenShift security settings for more information.

Comments or questions about this documentation? Contact us for support!