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

From Genesys Documentation
Jump to: navigation, search
(Published)
 
 
(7 intermediate revisions by 4 users not shown)
Line 2: Line 2:
 
|Standalone=No
 
|Standalone=No
 
|DisplayName=Security overview
 
|DisplayName=Security overview
|Context=Learn about the general security features involved in deploying Genesys Engage cloud private edition in OpenShift.
+
|Context=Learn about general security considerations involved in deploying Genesys Multicloud CX private edition.
 
|ComingSoon=No
 
|ComingSoon=No
 
|Section={{Section
 
|Section={{Section
 
|alignment=Vertical
 
|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===
 
===Built-in security features===
 +
Genesys Multicloud CX 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:  
  
*Containers are immutable and follow hardening best practices
+
*Containers are immutable and follow hardening best practices.
*Services run in least-privileged accounts based on the feature functionality needed by a given service
+
*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 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===
 
===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.
+
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.
 
In that context, here are additional security requirements for you to consider as you set up your environment.
Line 29: Line 32:
 
|sectionHeading=Pod security policies
 
|sectionHeading=Pod security policies
 
|alignment=Vertical
 
|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.
+
|structuredtext=Private edition does not support pod security policies.
 
|Status=No
 
|Status=No
 
}}{{Section
 
}}{{Section
 
|sectionHeading=Secrets
 
|sectionHeading=Secrets
 
|alignment=Vertical
 
|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, 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
+
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.  
*'''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 use only Kubernetes secrets at runtime, and they must support user-supplied values and secrets via Helm-value overrides.
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
 
|Status=No
 
}}{{Section
 
}}{{Section
 
|sectionHeading=Data encryption through TLS/SSL
 
|sectionHeading=Data encryption through TLS/SSL
 +
|anchor=DataEncryption
 
|alignment=Vertical
 
|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.
+
|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.
 +
 
 +
Genesys Multicloud CX services support TLS protocol for connections to third-party dependencies based on the details and capabilities of those dependencies. The credentials associated with each connection are managed through secrets associated with the relevant services.
 
|Status=No
 
|Status=No
 
}}
 
}}
 
}}
 
}}

Latest revision as of 04:02, March 31, 2023

Learn about general security considerations involved in deploying Genesys Multicloud CX private edition.

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.

Built-in security features

Genesys Multicloud CX 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.
  • 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.
  • 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 connections to datastores using Transport Layer Security (TLS) protocol.
  • 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

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

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.

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.

Data encryption through TLS/SSL

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.

Genesys Multicloud CX services support TLS protocol for connections to third-party dependencies based on the details and capabilities of those dependencies. The credentials associated with each connection are managed through secrets associated with the relevant services.

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