Configuring cluster security

Cluster security needs extra work and tools beyond Kubernetes to secure messages between its access points. While Kubernetes automates many of the tasks to deploy containerized applications, it does not manage the security of a cluster.

About this task

Kubernetes can be used to secure a containerized application, enforce role-based access control 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 OpenShift clusters to protect and secure your data:

OpenShift Transport Layer Security (TLS) and egress configuration

On OpenShift, the endpoints are exposed as OpenShift routes, and end to end TLS 1.2 communication is ensured. Some components are configured to use routes with "reencrypt", and others are configured with "pass-through". For more information, see https://www.openshift.com/blog/self-serviced-end-to-end-encryption-approaches-for-applications-deployed-in-openshift.

  • If reencrypt is used, the router’s TLS configuration is externally exposed. You must configure the appropriate TLS protocol and ciphers at the router level.
  • If pass-through is used, the server’s TLS configuration is externally exposed. Cloud Pak for Automation exposes only TLS 1.2 and secure ciphers.
TLS on OpenShift 3.11

TLS 1.0 and 1.1 are present by default. As described in https://docs.openshift.com/container-platform/3.11/architecture/networking/routes.html#ciphers, you use the profile "modern" to eliminate TLS 1.0, TLS 1.1, and some of the insecure ciphers. The following command sets the ciphers to "modern". 

oc set env dc/router ROUTER_CIPHERS=modern
TLS on OpenShift 4.3 and higher
Users must configure the TLS and ciphers for the cluster. The OpenShift Container Platform relies on the Ingress Controller resource for the TLS and cipher configuration. To configure TLS and ciphers, create a custom TLS profile. For more information, see https://docs.openshift.com/container-platform/4.3/networking/ingress-operator.html#nw-ingress-controller-tls-profiles_configuring-ingress. 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.
OpenShift egress firewall

In IBM Cloud Pak® for Automation, several modules invoke external services, and by design these modules do not know the exact invocation targets (IP addresses or domain names). Therefore, the related network policies for these modules do not restrict the egress traffic. If you do know the precise invocation targets on OpenShift, you can configure an egress firewall to limit the traffic to further secure your cluster. For more information, see https://docs.openshift.com/container-platform/4.3/networking/openshift_sdn/configuring-egress-firewall.html.

Protection of secrets and client data
Kubernetes secrets encryption

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 https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/. For extra security, you might also want to use an external Key Management Service (KMS) provider.

Database encryption

IBM Cloud Pak for Automation 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.

Persistent volume (PV) encryption

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 https://www.redhat.com/sysadmin/disk-encryption-luks.

Other security configurations
Password strength and account lockout

User Management Service (UMS) is the authentication and authorization service that is used in IBM Cloud Pak for Automation, and it is based on OpenId Connect. UMS is designed to connect with a corporate LDAP, and use all the existing users in the LDAP. The UMS LDAP connection is read-only, so UMS cannot write to the underline LDAP and lock the accounts. Therefore, it is important that users configure strong passwords and account lockout at the corporate LDAP level.

  • A lock cannot be made at the UMS connection level. A malicious user must use another connection (another application), possibly a round-robin password guess across many applications that are connected to the same LDAP.
  • An account lockout might cause a denial of service on system-to-system connections or API connections, as they have higher connection rates. The configuration needs to be managed carefully.