Security considerations

In a cloud environment, you must restrict access to your resources and data to authorized users. Data security can be built up by physical arrangements and software checks. Use zero trust principles and centrally managed deployments on dedicated servers that can be accessed only by authorized users. You must also protect your network with secure routes.

The following sections describe the key considerations to successfully secure your deployments on the cloud.

For more information about how to configure your OpenShift clusters to protect and secure your data, see Configuring cluster security.

FIPS enablement

A Cloud Pak for Business Automation deployment can be configured to be Federal Information Processing Standards (FIPS)-compliant. Cloud Pak for Business Automation FIPS enablement must be configured, as it is disabled by default. For more information, see FIPS compliance.

User management

User management is controlled by authentication and authorization functions.

Authentication
The ability for a user to identify themselves by using a username and password, token, or keys as having an account to access the platform.
Authorization
The distinct roles and authorizations that are attached to a user that define what actions they can complete on the platform. Examples include anonymous, view only, project based, cluster admin, and certain namespaces.

Various roles are often involved in the installation: developers, system and cloud administrators, operations, and DevOps teams. Each of these teams interacts with the infrastructure in a distinct way.

The cloud administration team is responsible for configuring the physical infrastructure for running your cluster. The operations team maintains the cluster through security settings, patching, upgrading, and scaling. DevOps teams configure continuous delivery activities, monitoring, logging, rolling upgrades, and deployments. Developers consume the API and the resources that are exposed by the infrastructure.

A Cluster Administrator is likely to create teams of users that need access to certain resources based on the Identity Management (IM) role. An IM role defines the actions that a user can take on the team resources.

The minimum RBAC role that is needed to install is the Operator role. However, if redeployment and cleanup are needed then the user needs to have the Administrator role. For more information, see Authentication types.

Similar to the way that RBAC resources control user access, administrators can use security context constraints (SCC) to control permissions for pods in addition to the Red Hat OpenShift default SCCs. These permissions include actions that a pod can take and what resources it can access. Privileged is the most relaxed SCC policy and must be used only for cluster administration. It gives complete control over the host worker nodes and containers, and the ability to run as any user, any group, any fsGroup, and with any SELinux context. Grant with caution, particularly in production, and monitor the access and actions of the administrators to spot bad behavior.

Security Context Constraints

All instances run in the default restricted security context constraint (SCC) that comes with OpenShift. For more information, see Managing Security Context Constraints in OpenShift.

HTTP vulnerabilities

By default, the deployed services are configured to accept communications over HTTPS. If you change the default deployment to allow communication over HTTP, the applications that use these services like the administration console for Content Platform Engine, can be vulnerable to denial of service (DoS and DDoS) attacks like Slowloris.

You can mitigate against these kinds of attacks by:

  • Putting an efficient HTTP proxy in front of your web or application servers.
  • Using hardware load balancers that accept only full HTTP connections.
    Note: Some restrictions exist when you use load balancers for Content Platform Engine. For more information, see Load balancer support for FileNet P8.
  • Using Mod_reqtimeout to set limits on the time it takes to receive an HTTP request.
    For example:
    <IfModule mod_reqtimeout.c>
    RequestReadTimeout header=20-40,MinRate=500 body=20,MinRate=500
    </IfModule>

You can also mitigate during the implementation by:

  • Refusing connections with abnormally small advertised window size.
  • Refusing persistent connections and HTTP pipe lining (unless performance benefits can be gained by accepting them).
  • Limiting the absolute connection life time to a reasonable value.
  • Tracking the rate at which a client is sending data and disconnecting when a bad client is identified.
  • Configuring the maximum transaction time for the client. If the sending message does not happen within the transaction time set at the server, drop the client connection.
  • Using an edge server that sets its buffer and passes on the data over to the application server only when the buffer is full.

Routes, ingress, and egress

Routes are used to provide external access to cluster resources. External access is provided by routes, egress, or ingress. Cloud Pak for Business Automation secures the routes of its services by using transport layer security (TLS) termination to serve certificates to the client.

The following ciphers can be used for TLS communications:
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

All dependent services, including database servers and LDAP servers, must configure one of these four ciphers to secure communication with the Cloud Pak for Business Automation components.

To mitigate potential attacks on your Cloud Pak for Business Automation deployments, outbound connections are limited by default to a minimum to deny all egress.
  • Network policies are created during the installation for specific pods to connect to the services that they need.
  • Network policies are created for traffic between the Cloud Pak for Business Automation components and the Cloud Pak foundational services.
  • Network policies are created for traffic to known endpoints like databases.

In a development environment, you might set the sc_restricted_internet_access custom resource parameter to false because you cannot know where the applications are calling. In a production environment, it is important to set the sc_restricted_internet_access parameter to true, and to create additional egress network policies to specifically allow communication to trusted external destinations. You can create the egress network policies with a single network policy or individual network policies for each capability. For more information about the capabilities that need to access external services, see Configuring cluster security.

Secrets

A root certificate authority (CA) secret stores the root CA TLS key and certificate. Every component also trusts the certificates that are stored in a certificate list, which can be configured in an operator instance. For more information, see Managing certificates.

Components that are accessed through the IBM Cloud Pak Platform UI (or Zen UI), including Business Automation Studio and the Cloud Pak designers, do not have external routes that can be accessed directly. To configure user access from Zen UI, add all the users that need to use these Cloud Pak components to the Automation Developer role. For more information, see Predefined roles and permissions.

The following tables provide the minimum set of secrets that need to be created for a Cloud Pak deployment. It does not include the secrets that you can set at the component level. Component-level parameters always take precedence over the shared configuration parameters.

Every component route potentially needs two certificates:
  • A TLS certificate that is stored in a TLS secret.
  • An optional CA signer that is stored in a generic Kubernetes secret.
Note: When you create secrets, special characters such as $, \, *, =, and ! are interpreted by your shell, and therefore need escaping. In most shells, the simplest way to escape a password is to surround it with single quotation marks ('). For example, if your password is S!B\*d$zDsb= then run the command with single quotation marks around the password string.
kubectl create secret generic dev-db-secret \
   --from-literal=username=devuser \
   --from-literal=password='S!B\*d$zDsb='

You do not need to escape special characters in passwords from files (--from-file). For more information, see Managing Secrets.

Table 1. Shared configuration parameters for Cloud Pak certificates
Parameter Value type Description
shared_configuration
root_ca_secret TLS secret Root CA for all internal services.
external_tls_certificate_secret TLS secret Wildcard certificate for all external routes. The certificates must be in Privacy Enhanced Mail (PEM) files.
sc_ingress_tls_secret_name TLS secret Ingress certificate for Red Hat OpenShift Kubernetes Service (ROKS).
Table 2. Shared configuration parameters for certificates that are externally trusted
Parameter Value type Description
trusted_certificate_list Array of secret names Trusted certificate list of external services.
lc_ldap_ssl_secret_name Secret LDAP server certificate.