PrivateEdition/Current/PEGuide/SecurityOverview - Revision history

WikiSysop at 04:02, March 31, 2023

2023-03-31T04:02:03Z

WikiSysop at 00:30, April 20, 2022

2022-04-20T00:30:25Z

Ed.jamer@genesys.com: Text replacement - "Genesys Cloud" to "Genesys Cloud CX"

2021-11-09T21:28:22Z

Text replacement - "Genesys Cloud" to "Genesys Cloud CX"

Ed.jamer@genesys.com: Text replacement - "Genesys Engage" to "Genesys Multicloud CX"

2021-11-09T21:12:57Z

Text replacement - "Genesys Engage" to "Genesys Multicloud CX"

Ed.jamer@genesys.com: Text replacement - "Genesys Engage [cC]loud" to "Genesys Multicloud CX"

2021-11-09T20:29:50Z

Text replacement - "Genesys Engage [cC]loud" to "Genesys Multicloud CX"

Jose.druker@genesys.com: Published

2021-09-20T17:59:09Z

Published

Jose.druker@genesys.com: Published

2021-09-14T19:54:22Z

Published

Richard.pfeiffer@genesys.com: Published

2021-08-16T18:29:23Z

Published

Richard.pfeiffer@genesys.com: Published

2021-07-01T00:46:41Z

Published

New page

{{Article
|Standalone=No
|DisplayName=Security overview
|Context=Learn about the general security features involved in deploying Genesys Engage cloud private edition in OpenShift.
|ComingSoon=No
|Section={{Section
|alignment=Vertical
|structuredtext=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.

===Overrides===
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 {{Link-SomewhereInThisVersion|manual=PEGuide|topic=HelmOverrides|display text=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.
|Status=No
}}{{Section
|sectionHeading=Pod security policies
|alignment=Vertical
|structuredtext=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.
|Status=No
}}{{Section
|sectionHeading=Secrets
|alignment=Vertical
|structuredtext=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.

===Kubernetes secrets===
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.
|Status=No
}}{{Section
|sectionHeading=Adhering to CIS Benchmark guidelines
|alignment=Vertical
|structuredtext=Content coming soon.
|Status=No
}}{{Section
|sectionHeading=Data encryption through TLS/SSL
|alignment=Vertical
|structuredtext=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.
|Status=No
}}
}}

@@ Line 17: / Line 17: @@
 *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.
+<!--* 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 host-based intrusion detection system (HIDS), file integrity management (FIM), user and entity behavior analytics (UEBA), and so on.

@@ Line 39: / Line 39: @@
 |structuredtext=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.
+Most of the services require secrets at deployment time, for dependencies such as Postgres, Redis, Email Server, Genesys Cloud CX, and so on.
 You must use only Kubernetes secrets at runtime, and they must support user-supplied values and secrets via Helm-value overrides.

@@ Line 17: / Line 17: @@
 *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.
+*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.

← Older revision		Revision as of 18:29, August 16, 2021
Line 11:		Line 11:

	===Built-in security features===		===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:		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:

@@ Line 2: / Line 2: @@
 |Standalone=No
 |DisplayName=Security overview
-|Context=Learn about the general security features involved in deploying Genesys Multicloud CX private edition in OpenShift.
+|Context=Learn about general security considerations involved in deploying Genesys Multicloud CX private edition.
 |ComingSoon=No
 |Section={{Section
 |alignment=Vertical
-|structuredtext=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.
+|structuredtext=Because security is a growing priority for today's enterprises, 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.
+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===
@@ Line 19: / Line 19: @@
 *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.
+*You can put security tool agents on your Kubernetes nodes to carry out the appropriate security tasks, such as host-based intrusion detection system (HIDS), file integrity management (FIM), user and entity behavior analytics (UEBA), 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.
+*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 support encryption of their data at rest as well secure connections to datastores using Transport Layer Security (TLS) protocol.
-*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.
+*Appropriate Center for Internet Security (CIS) benchmarks are generally built into services' container images and are applied to how Kubernetes node resources are accessed. Please see specific service documentation for limited exceptions and specific requirements.
 ===Overrides===
-We recognize that your own stringent security requirements can differ from those that are enabled by default in Genesys Multicloud CX. You can customize many of these security requirements by {{Link-SomewhereInThisVersion|manual=PEGuide|topic=HelmOverrides|display text=overriding}} Helm chart values, in accordance with the information in the appropriate service guide.
+Genesys recognizes that your own stringent security requirements can differ from those that are enabled by default in Genesys Multicloud CX services. You can customize many of these security requirements by {{Link-SomewhereInThisVersion|manual=PEGuide|topic=HelmOverrides|display text=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.
@@ Line 37: / Line 37: @@
 |sectionHeading=Secrets
 |alignment=Vertical
-|structuredtext=Secrets are namespace objects that contain a small amount of sensitive data such as a password, a token, or a key.
+|structuredtext=Secrets are namespace objects that contain a small amount of sensitive data, such as a password, a token, or a key. Most of the Genesys Multicloud CX services require secrets at deployment time, for dependencies, such as Postgres, Redis, email server, Genesys Cloud CX, and so on.
-Most of the services require secrets at deployment time, for dependencies such as Postgres, Redis, Email Server, Genesys Cloud CX, and so on.
+The scope of a secret is the namespace in which the secret is created. Unless you are using a single namespace for all private edition services, in each namespace you must create secrets for the third-party dependencies that are required by the service(s) in that namespace. If a secret is shared by different services in different namespaces, you must duplicate the secret in all the respective namespaces. Depending on how complex you want to make management of credentials for shared datastores and other shared dependencies, you can either replicate the same secret across multiple namespaces, so that different services use the same credentials for a given datastore, or create different secrets in each namespace, so that individual services use their own credentials for a given datastore.
 You must use only Kubernetes secrets at runtime, and they must support user-supplied values and secrets via Helm-value overrides.
 |Status=No
 }}{{Section
 |sectionHeading=Data encryption through TLS/SSL
 |alignment=Vertical
-|structuredtext=The Genesys Multicloud CX 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.
+|structuredtext=Genesys Multicloud CX services support TLS protocol for connections into the cluster up to the ingress controller. Data is not encrypted beyond the ingress controller.
 |Status=No
 }}
 }}