Learn about the general security features involved in deploying Genesys Engage cloud private edition in OpenShift.
Because security is a growing priority for today's enterprise, Genesys works hard to provide a full range of security-related features such as authentication, role-based access control (RBAC), and many more.
Note, however, that you are responsible for maintaining the security of your private edition infrastructure—such as network security, firewalls, and so on.
Built-in security features
Genesys Engage cloud private edition has been developed using industry-standard tools and best practices to identify and eliminate security vulnerabilities.
The services that ship with private edition are built with the following features, which provide a strong basis for you to create a secure, enterprise-grade solution:
- Containers are immutable and follow hardening best practices.
- Services run in least-privileged accounts based on the feature functionality needed by a given service.
- Private edition supports the use of arbitrary UIDs in OpenShift environments.
- You can deploy your Kubernetes clusters into different network segments to partition software into security zones. To do this, you must create new Kubernetes Service Objects with load balancers, which expose the necessary connections between Kubernetes clusters.
- You can put security tool agents on your Kubernetes nodes to carry out the appropriate security tasks, such as HIDS, File Integrity Management, EUBA, and so on.
- If you need encryption in transit within the cluster, you can use a service mesh, or various cloud-native solutions. You can also enable encryption in transit outside the cluster by using an ingress controller.
- Private edition services support encryption of their data at rest as well secure connection to data stores using TLS.
- Private edition services generally follow key CIS benchmarks with respect to access to Kubernetes node resources. Cases in which these benchmarks are not followed are documented.
We recognize that your own stringent security requirements can differ from those that are enabled by default in Genesys Engage. You can customize many of these security requirements by overriding Helm chart values, in accordance with the information in the appropriate service guide.
In that context, here are additional security requirements for you to consider as you set up your environment.
Pod security policies
Private edition does not support pod security policies.
Secrets are namespace objects that contain a small amount of sensitive data such as a password, a token, or a key.
Most of the services require secrets at deployment time, for dependencies such as Postgres, Redis, Email Server, Genesys Cloud, and so on.
You must use only Kubernetes secrets at runtime, and they must support user-supplied values and secrets via Helm-value overrides.
Except in Azure Kubernetes Service (AKS), all secrets are namespace secrets.
- Namespace secrets are secrets to third-party dependencies that are only used by the services within a specific namespace. If a secret is shared by different services in different namespaces, the secret must be duplicated in all the respective namespaces.
- (For AKS only) Shared secrets are secrets to third-party dependencies that are used by services that are hosted in different namespaces. For example, the Tenant Service Postgres database is accessed as read-only by the GWS Config service, which is hosted in a different namespace.
Adhering to CIS Benchmark guidelines
Data encryption through TLS/SSL
The Genesys Engage services support the TLS capabilities of the third-party dependencies, based on the details provided by those dependencies, and only up to the ingress controller. Data is not encrypted beyond the ingress controller. The credentials associated with each connection are managed through secrets associated with the relevant services.