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 on network policies and how to configure your OpenShift clusters to protect and secure your data, see Configuring cluster security.

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 expected to be involved in the installation of IBM Cloud Pak® for Business Automation: developers, system and cloud administrators, operations, and DevOps teams. Each of these teams, interact 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 and Access Management (IAM) role. An IAM role defines the actions that a user can take on the team resources.

The minimum RBAC role that is needed to install Cloud Pak for Business Automation is the Operator role. However, if redeployment and cleanup are needed then the user needs to have the Administrator role. For more information, see Role-based access control (RBAC).

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 of Cloud Pak for Business Automation run in the default restricted security context constraint (SCC) that comes with OpenShift. For more information, see Managing Security Context Constraints in OpenShift.

Routes

Routes are used to provide external access to cluster resources. All external traffic into Cloud Pak for Business Automation enters through the Cloud Pak Platform UI (Zen) front door, which is created by the IBM Cloud Pak foundational services. Cloud Pak for Business Automation secures the access to its services by using transport layer security (TLS) termination to serve certificates to the client. A customized TLS certificate needs to be configured at Zen's front door (AutomationUIConfig).

A root certificate authority (CA) secret stores the root CA TLS key and certificate, which is used to sign all internal certificates for internal communications. In most cases, the value does not need to be changed. 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 and AutomationUIConfig.

To configure user access to the 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.

Secrets

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 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.
Note: Component-level parameters always take precedence over the shared configuration parameters.

Kubernetes API access required for Business Automation Studio

Business Automation Studio creates two service accounts for pods to use, based on the name of the custom resource (cr):
  • <cr-name>-bastudio-sa
  • <cr-name>-bastudio-int
The init service account is used only by the LTPA job. It binds the <cr-name>-bastudio-int role with the following access to the secret:
resources:
  - secrets
  verbs:
  - get
  - create
  - update
  - delete
  - patch
The <cr-name>-bastudio-int role is used by the Business Automation Studio pod. It is not bound to any role or cluster role and does not require additional access.