Security considerations

Security context constraints (SCC)

Administrators can use SCCs to control permissions for pods on their Red Hat OpenShift Container Platform cluster. These permissions include actions that a pod can perform and what resources it can access. Red Hat OpenShift Container Platform clusters contain default security context constraints (SCCs). IBM Cloud Pak for AIOps runs with the restricted or restricted-v2 SCC that is included within this default set of constraints. For more information, see Red Hat® OpenShift® Container Platform SCCs and Red Hat - Managing Security Context Constraints .

Note: SecurityContextConstraints do not apply to the default or kube-system namespaces.

Permissions

For more information about the permissions that are required for Infrastructure Automation, see Permissions.

Volume level encryption

You can configure Portworx encryption or host-level encryption, depending on your requirements. Decide which level of encryption is needed for each stateful data store in your environment.

• For more information about using encrypted volumes on Red Hat OpenShift Container Storage, see Creating a storage class for persistent volume encryption .

• For more information about using the encryption feature for Portworx volumes, see Create encrypted PVCs .

Security hardening

For production environments, ensure that the Red Hat OpenShift Container Platform cluster where you are installing Infrastructure Automation is configured securely. To help harden the security for your cluster, consider completing the following tasks:

• Configure the Red Hat OpenShift Container Platform to enable etcd data encryption. For more information, see the Red Hat documentation about Encrypting etcd data .

• Implement a network egress policy that strictly controls what outbound calls can be made from applications in the cluster and from the Infrastructure Automation project (namespace). For more information, see the Red Hat documentation about Creating a network policy .

• If you use your own certificate authority (CA), replace the default certificate manager CA with your own CA.

• Ensure that your Red Hat OpenShift Container Platform and Kubernetes environment is configured according to the Center for Internet Security (CIS) Benchmark for Red Hat Enterprise Linux based OpenShift V4 and Kubernetes V1.6 security hardening. For more information, see the Center for Internet Security (CIS) Benchmarks about Securing Kubernetes .

• Configure lockout mechanisms on your authentication server to handle excessive login attempts.

• Shorten session timeouts to the shortest tolerable duration.

• Use your own certificate authority and monitor certificate expiration dates.

• Configure rate limiting connections for basic protection against distributed denial-of-service (DDoS) attacks. For more information about how to configure this limiting, see the Red Hat documentation about Route configuration .

• Limit users from viewing information about other users. By default, user IDs, user groups, roles, and permissions for other users are visible to users. To block non-administrative users from viewing user groups, roles, and permissions,

  1. Edit the config map product-configmap to add the configuration usermgmt_limit_user_info: "true".

  2. Restart the user management pods, by running the following command:

     oc delete pod -l component=usermgmt
     

Protecting against HTTP Host header attacks

The mandatory request header specifies the domain that you want to access can be altered as part of an exploitative attack. If your installation does not use a load balancer or proxy that depends on http HOST headers, then use the following steps to enable HTTP Host header injection protection:

1. Ensure that the HTTP Host header matches the value of URL_PREFIX from the ConfigMap product-configmap. If necessary, specify the project (namespace) of your Infrastructure Automation deployment.

2. In configmap product-configmap, add or edit the HOST_INJECTION_CHECK_ENABLED entry and set its value to true. To set the entry by using the Red Hat OpenShift, select the product-configmap in your Infrastructure Automation project (namespace). From the menu, select Edit configmap. On the YAML page, find or add the HOST_INJECTION_CHECK_ENABLED entry, and set the value to true.

3. Restart the ibm-nginx-* pods.

   • If you are using the Red Hat OpenShift console, select the pods and use the delete pod action.

   • If you are using the CLI, use the oc delete <pod-name> -n <namespace> command.

     Where <namespace> is the project (namespace) of your Infrastructure Automation deployment.

If you need to disable this protection for any reason, remove the HOST_INJECTION_CHECK_ENABLED entry, or set its value to false, and restart the Nginx pods.

Certificates

If you want to use a custom certificate for Infrastructure Automation, then you can do this with either of the following methods:

• Configure a custom certificate for the Red Hat OpenShift cluster. Follow the instructions in the Red Hat OpenShift documentation Replacing the default ingress certificate. Then, deploy the signing CA certificate into the cluster by following the instructions in the Red Hat OpenShift documentation Replacing the CA Bundle certificate.
• If you would like to use a custom certificate for IBM Cloud Pak for AIOps or Infrastructure Automation only, then after installation is complete follow the instructions in Using a custom certificate.