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
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
- 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 provide pod security policies or Azure policies. However, each service guide provides information on exceptions to access node resources. Use this information to configure the Helm override attribute provided with each service, in order to create and apply the appropriate policies for controlling your Kubernetes platform.
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.
Categories of secrets
There are two categories of secrets:
- Namespace secrets are secrets to third-party dependencies that are only used by the services within a specific namespace
- 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.
You must only use the Kubernetes secrets for OCP and AKS at runtime, and they must support user-supplied values and secrets via Helm-value overrides.
Adhering to CIS Benchmark guidelines
Content coming soon.
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. The credentials associated with each connection are managed through secrets associated with the relevant services.