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 OpenShift clusters to protect and secure your data:

• Network policies
• OpenShift Transport Layer Security (TLS) and egress configuration
• Protection of secrets and data

Network policies

Cloud Pak for Business Automation uses network policies to control the connections between its pods and the ingress and egress traffic. The network policies restrict traffic to the pods and have the following properties.

• Legitimate pod-to-pod connections are allowed when explicitly permitted.
• Required pod egress traffic is allowed.

If you want to harden your network security, for example by introducing a "deny-all" policy, then you must allow explicitly the following traffic:

• Ingress traffic from OpenShift Ingress Controller (Router).
• Ingress traffic from OpenShift Monitoring.
• Traffic between pods in the same Cloud Pak for Business Automation namespace.
• Egress traffic to external services (database servers and directory service server or LDAP) from your Cloud Pak for Business Automation namespace. You must customize your network policies to allow this traffic.
• Import and install network policies for IBM Cloud Pak foundational services. For more information, see Installing network policies for foundational services.

The following example sets a network policy to allow ingress traffic from OpenShift Ingress Controller (Router):

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-ingress
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: ingress
  podSelector: {}
  policyTypes:
  - Ingress

The following example sets a network policy to allow ingress traffic from OpenShift Monitoring:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-openshift-monitoring
spec:
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          network.openshift.io/policy-group: monitoring
  podSelector: {}
  policyTypes:
  - Ingress

The following example sets a network policy to allow traffic between pods in the same Cloud Pak for Business Automation namespace:

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: allow-same-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector: {}

Note: The pod selectors (podSelector) in these examples are for all pods. Therefore, all the pods deny traffic that is not explicitly allowed by the network policies of the namespace.

If the deny-all network policy is defined in the cluster as shown in the following NetworkPolicy, then create another policy to allow traffic from the operator pods to the API server/master nodes.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress 

The following example shows a network policy that allows traffic to the API server by setting a value for the Classless Inter-Domain Routing (CIDR). The CIDR is a method for allocating IP addresses for IP routing.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-api-server
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
    - to:
      - ipBlock:
          cidr: <your-IP> 

For more information about getting the CIDR block IPs, see Viewing the cluster network configuration.

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 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 Business Automation exposes only TLS 1.2 and secure ciphers.

TLS on OpenShift

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

OpenShift egress firewall

In IBM Cloud Pak® for Business 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 Configuring an egress firewall for a project.

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

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

Encryption of data at rest

If sensitive information is generated and stored in a database for IBM Cloud Pak for Business Automation, it is recommended to encrypt the database content. If you are using native database encryption, see the database encryption documentation for more information. The encryption of the data at rest is not visible to the IBM Cloud Pak for Business Automation 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.