Security considerations
The following sections describe the key considerations to successfully secure your deployments on the cloud.
- FIPS enablement
- User management
- Security Context Constraints
- HTTP vulnerabilities
- Routes, ingress, and egress
- Secrets
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.
- 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.
- 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.
- 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. 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). |
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. |