Preparing to secure your cluster

When you install IBM® Cloud Private, you create a secure connection from the boot node to all other nodes in your cluster. You can either set up SSH or set up password authentication in your cluster. For installation steps, see Installing IBM Cloud Private Cloud Native, Enterprise, and Community editions.

After you install, you can secure the access to your cluster through role-based access control (RBAC), single sign-on (SSO), and Lightweight Directory Access Protocol (LDAP). You can manage Helm repositories, and create namespaces, teams, and security policies for pods and containers. For more information, see the Security guide.

Security considerations

As you design your security for IBM Cloud Private, you must understand the following information:

• The type of workloads that you are going to run.
• The type of external interactions that you need for the applications.
• The way of interacting with the platform and the interfaces that you are going to use.
• The different integrations for Identity and Access Management (IAM) and other security components.
• The isolation and segmentation that is needed for the different groups and teams.
• The data protection needs for the different workloads.
• The way containers need to be secured and monitored for mutations.

Interacting with IBM Cloud Private

Understanding who and how people interact with the cluster helps you to configure IAM. To determine the access and authorizations, you must understand the target operations model for the clusters that you are using. Ask the following questions:

• Who is going to do the cluster management?
• Who is deploying and managing applications?
• What operations are needed by the teams?
• Is a multi-tenant approach that includes logging and monitoring needed?
• What authentication integrations are needed?

Pay special attention to the different integration points, such as the continuous integration and continuous delivery (CICD), as these points determine the different service accounts and the authorizations that the accounts need.

When you use a CICD deployment tool with permissions to deploy containers, you must limit access and deployments with a service account and not allow any other user to create these deployments.

For more information, see Configuring LDAP connection and Pod isolation in the Security guide.

Handling certificates

Certificates are used for the following interactions:

• Intra-service communications:
  • Platform services, such as logging, monitoring, metering, and security.
  • Core services, such as Kubernetes and etcd.
• External facing endpoints, such as image manager, Docker registry, management ingress, Liberty, and Helm.
  • Both built-in (self-signed) and user-provided certificates are supported.
  • Used by workloads that are running on top of IBM Cloud Private (proxy ingress)

Certificate lifecycle is managed either manually or by using the IBM Cloud Private Certificate manager (cert-manager) service:

• The cert-manager service is used to generate and manage certificates and includes auto renewal.
• Based on the Kubernetes community project cert-manager .
• Issuer types that are supported: Certificate authority (CA), self-signed, and HashiCorp Vault server.

For more information, see the following topics:

• Using IBM Cloud Private Certificate manager (cert-manager)
• Creating IBM Cloud Private Certificate manager (cert-manager) certificates

Data encryption

Data in transit:

• TLS and IPSec are used to provide data-in-transit protection.
• Management ingress controller exports TLS, which can be used by APIs that use TLS as a front end.
• All inter-node data traffic can be encrypted out-of-the box by using IPSec without changing any application. For details, see Encrypting cluster data network traffic with IPsec.
• Both TLS and IPSec can be configured to use Federal Information Processing Standard (FIPS) compliant ciphers.

Data at rest:

• Any IBM Cloud Private state can be protected by using a file-system-level or block-device-level encryption that is outlined in Encrypting volumes by using dm-crypt.
• FIPS-compliant ciphers can be used.
• The Kubernetes AES-CBC encryption provider can be enabled to encrypt secrets. For details, see the Kubernetes topic Encrypting Secret Data at Rest .
• All IBM Cloud Private secrets are accessible only to users who have either the cluster administrator or team administrator role.

You can encrypt the file systems that are used by IBM Cloud Private with Linux® Unified Key Setup (LUKS) encryption in Linux. Ensure that your system has available disk space. dm-crypt provides transparent encryption of block devices. You can access the data immediately after you mount the device. By default, data in transit encryption is disabled in your IBM Cloud Private cluster.

For more information, see the following topics:

• Enabling FIPS on operating systems that use IBM Cloud Private
• Encrypting Kubernetes secrets with Key Management Service plug-in
• Managing Secrets

Securing your images

IBM Cloud Private has a private image repository that is based on the Docker registry within the cluster. The following list highlights some of the benefits of using IBM Cloud Private to secure your images:

• Bundled images: You can either import Docker images from the bundle into the private registry, or import any Docker image that you want to deploy across your nodes.
• Secure access: Add only the images you approve of so that your Developers have trusted and validated images to build from.
• Image repository location: All local Docker registry images are located in the master node. If there are multiple master nodes, the registry is distributed across the master nodes in active mode.
• External repositories: Vulnerability Advisor cannot scan the external repositories.

You can restrict which repository images can be deployed from. You can also enforce Vulnerability Advisor policies. If an image does not meet defined policy requirements, the pod is not deployed. If you use the Vulnerability Advisor, the internal image repository needs to be used.

Securing your containers

When you secure your containers, the main goal is to provide visibility, control, and analytics to access and enforce security and compliance on your applications and data that are running in the private cloud. You can achieve these goals with Vulnerability Advisor and Mutation Advisor.

Vulnerability Advisor benefits:

• Developers can design secure applications with little effort
• No setup required
• No agents or guest credentials are needed by xSP
• Tamper proof
• Support near real-time vulnerability assessment of images
• Simple to interpret results

Are your containers unmutable?

With IBM Cloud Private, you can track changes of a container on files and processes. System integrity monitoring is an important part of several compliance and audit requirements, including Payment Card Industry Data Security Standard (PCI/DSS).

The Mutation Advisor continuously monitors containers for the state of files and processes at a given sampling. It reports modular changes in the state on the Mutation Advisor user interface that is in the profile whitelist, as normal changes for the container. The reports can be viewed as notifications of mutations on a container by container basis, and a timeline for each container. Mutation Advisor fills an existing gap in requirements for container integrity monitoring.

For more information, see Vulnerability Advisor.