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. 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.
- 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.
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.
Secrets
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.
- A TLS certificate that is stored in a TLS secret.
- An optional CA signer that is stored in a generic Kubernetes secret.
$, \,
*, =, 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.
| 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. |
| sc_ingress_tls_secret_name | TLS secret | Ingress certificate for Red Hat OpenShift Kubernetes Service (ROKS). |
| 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. |