Configuring cluster security

Kubernetes can be used to secure a containerized application, enforce role-based access control (RBAC) policies, and restrict the ability of a container to access resources on the host server. Communications need authentication in Kubernetes to minimize the risk that an attack in one pod does not spread to other pods.

The following sections provide guidance on how to configure your clusters to protect and secure your data:

• Secure custom routes and ingress
• Proxy servers
• Transport Layer Security (TLS) and cipher configuration
• Protection of secrets and data

Secure custom routes and ingress

It is recommended to use secure communication protocols for services, so make sure that your custom routes and ingresses from the FNCM endpoints are not configured with the unsecured port 9080.

The default routes and ingresses created by the operator use the secured port 9443.

Proxy servers

By default, FNCM uses fully qualified hostnames when it connects to external services. If you configured a proxy for outbound connections to external services, then set the NO_PROXY environment variable in the cluster to "*.svc". The variable enables all the internal connections to work in a proxy-enabled environment.

NO_PROXY=*.svc

Transport Layer Security (TLS) and cipher configuration

OCP relies on the OpenShift Ingress Controller (Router) for the TLS and cipher configuration. To configure TLS and ciphers, create a custom TLS profile. For more information, see Ingress controller TLS profiles . The following command provides an example configuration.

oc patch --type=merge \ 
--namespace openshift-ingress-operator ingresscontrollers/default \ 
--patch 
'{"spec":
    {"tlsSecurityProfile":
        {
        "minTLSVersion": "VersionTLS12",
        "type": "Custom",
        "custom": {
            "ciphers": ["ECDHE-ECDSA-AES256-GCM-SHA384",
                        "ECDHE-ECDSA-AES128-GCM-SHA256",
                        "ECDHE-RSA-AES256-GCM-SHA384",
                        "ECDHE-RSA-AES128-GCM-SHA256",
                        "AES256-GCM-SHA384",
                        "AES128-GCM-SHA256"],
            "minTLSVersion": "VersionTLS12"}
        }
    }
}'

The following information is used in the configuration.

• A custom TLS profile must be created. The other predefined TLS profiles (Old, Intermediate, Modern) do not accept a list of explicit ciphers, and expose known TLS vulnerabilities.
• The list of ciphers does not include any CBC ciphers, and it includes two ciphers for Elliptic Curve certificates (the first two ciphers), and four ciphers for RSA certificates.
• The configuration needs to be applied once per cluster.
• The configuration can be displayed by using the status command.

  oc get Ingresscontroller/default -n openshift-ingress-operator -o yaml

  The command displays a "tlsProfile" section with the pertinent fields, which shows that the command worked.

• You can also verify the configuration by using a browser to visualize the chosen cipher, or use other known TLS tests.

Protection of secrets and data

Encryption of Kubernetes secrets

By default, the Kubernetes master (API server) stores secrets as base64 encoded plain text in etcd.

Cluster administrators need to do extra steps to encrypt secret data at rest. For more information, see Encrypting Secret Data at Rest . For extra security, you might also want to use an external Key Management Service (KMS) provider.

Encryption of data in transit

The container deployment uses a number of databases. Database connections from the consumers to the databases are internal cluster connections, and the network policy forbids egress traffic for pods that run a database.

By default, all components configure the database connections with Secure Sockets Layer (SSL). If you use a component that provides a configuration setting to enable SSL, then you must enable it.

Encryption of data at rest

If sensitive information is generated and stored in a database, it is recommended to encrypt the database content. For more information about native database encryption, see the documentation. The encryption of the data at rest is not visible to the FNCM applications.

Encryption of persistent volumes (PVs)

Persistent volumes must be configured on a cluster as part of the preparation of a deployment. PVs need to be encrypted at disk level to protect the data stored in them. Several vendors provide encryption solutions. It is also possible to use disk encryption, such as Linux® Unified Key Setup (LUKS). For more information, see Configuring LUKS: Linux Unified Key Setup .