This is a cache of https://docs.openshift.com/dedicated/3/product_security/red_hat_responsibilities/dedicated_network_security.html. It is a snapshot of the page at 2024-11-21T05:04:55.672+0000.
Network Security - Red Hat Responsibilities | Security | OpenShift Dedicated 3
    Soon, all Red Hat OpenShift documentation will only be available on docs.redhat.com, the official location of all Red Hat product documentation. Get familiar with the updated experience today!
  1. Documentation
    2. history bug_report picture_as_pdf
×

Network Security

Network Segregation

OpenShift Dedicated uses a software-defined networking (SDN) approach to provide a unified cluster network that enables communication between pods across the cluster. This pod network is established and maintained by the OpenShift SDN, which configures an overlay network using Open vSwitch (OVS).

By default, OpenShift Dedicated uses the ovs-networkpolicy plug-in, which allows project administrators to configure their own isolation policies using NetworkPolicy objects. These policies can be fully managed by project owners and dedicated-admin users to add network-level isolation for the projects.

Additionally, some OpenShift Dedicated clusters also support the ovs-multitenant plug-in, which provides project-level isolation for pods and services. Each project receives a unique Virtual Network ID (VNID) that identifies traffic from pods assigned to the project. By default, pods from different projects cannot send packets to or receive packets from pods and services of a different project. However, the cluster administrator can join projects and later isolate them using admin commands. For more information on pod network management, see Managing Networking.

Security Groups

Security groups are provided by the cloud provider. They provide security at the protocol and port access level. Each security group works similar to a firewall and has a set of rules that filter traffic coming into and out of a node.

OpenShift Dedicated has separate security groups configured for the following components:

  • master nodes

  • infrastructure nodes

  • compute Nodes

  • etcd

  • router ELB

  • External master ELB

  • Internal master ELB

Encryption for Data at Rest

All new persistent volumes (PVs) are encrypted at rest. PVs are backed by block storage, which is Read-Write-Once and will be dynamically provisioned and recycled based on application requests.

Encryption for Data in Transit

All communication channels with the REST API, as well as between master components such as etcd and the API server, are secured with TLS. TLS provides strong encryption, data integrity, and authentication of servers with X.509 server certificates and public key infrastructure. By default, a new internal PKI is created for each deployment of OpenShift Dedicated. The internal PKI uses 2048 bit RSA keys and SHA-256 signatures.

The OpenShift Dedicated server and oc client provides TLS 1.2 or newer by default. Both server and client prefer modern cipher suites with authenticated encryption algorithms and perfect forward secrecy. Cipher suites with deprecated and insecure algorithms such as RC4, 3DES, and MD5 are disabled. Some internal clients (for example, LDAP authentication) have less restricted settings with TLS 1.0 to 1.2 and more cipher suites enabled.

Network End-point Security

OpenShift Dedicated includes security certificates needed for both internal and external services on the cluster. For external routes, there are two separate wildcard certificates that are provided and installed on each cluster. For clusters that use an additional router shard and ELB, there will be a third wildcard certificate.

For cluster services such as the API and web console, the wildcard certificate is:

*.[cluster-name].openshift.com

For application routes, the wildcard certificate is:

*.[shard-id].[cluster-name].openshiftapps.com

Custom domains and subdomains are not available for the platform service routes or the default application routes. However, you can upload your own certificates for custom application routes through the web console or API.