Security Considerations
This document describes the actions that you can take to ensure that your installation is secure, customize your security settings, and set up user access controls in IBM® DevOps Test Hub (Test Hub).
- Enabling secure communication between multiple applications
- Ports, protocols, and services
- Customizing your security settings
- Setting up user roles and access
Customize this topic for your product, keeping or removing whichever sections are appropriate. Attach this security topic in the master navigation file to the anchor above the Notices topic.
Do not change the topic title, but customize the content of the topic to make sure it applies to your product. The content of the topic is a series of suggested areas of security documentation that may or may not apply to your product, such as SSL certificate management, enabling HTTPS, enabling LDAP for authentication, customizing error pages, configuring security roles, changing default passwords, securing silent installs, and anything else that a customer should consider when making their installation as secure as possible. By default the installation documentation should descibe a secure install; but this topic is the place to explain how it is secure, and to point to information on how the customer can make changes that they might need.
You can add information directly to this topic, or use it as a top-level security topic and add links to your pre-existing topics.
Your security SME should provide you with all the required information. The official list of SMEs by product is here:
Enabling secure communication between multiple applications
For integrated products, answer these questions:
- How do you secure communications between them?
- How are user access controls handled between the products?
- How do you configure single-sign on, and what are the implications of doing so?
For information about how the self-signed certificate was created, see the
ssl.sh file in the <install-directory>/prepare/
directory.
For information about importing a certificate authority trusted by your organization, see Certificate authority: Importing and extending lists.
Communications between containers are in plaintext by default, and they can be secured only if the Container Network Interface (CNI) supports encryption.
Ports, protocols, and services
Answer questions such as these:
- Do internal processes, tasks, or services require a fixed user ID?
- If you can create your own user ID for these processes, tasks, or services, how do you associate the user ID with them?
- What ports, protocols, and services does the application use?
TCP port 443 is used by the majority of communications with the server.
The port 7085 is the default port for communications with agents registered with Test Hub.
The ports starting from 7085, are used in pairs such as 7085 and 7086, and are allotted for the Schedule that is executed first. The next Schedule is allotted the next pair (7087,7088), and so on for the Schedules that are running simultaneously.
You must open the required ports in pairs for each of the Schedules that you want to run simultaneously.
Customizing your security settings
Provide information from the answers to these questions:
- Are default user IDs and passwords created automatically? Which of these can be changed and how?
- How do you customize error pages that your users might encounter?
- Can you enable mulitple levels of security, and what are the implications of each?
- Can users set up notifications of security breaches or attempts?
- Where is information about login attempts stored?
- Are passwords saved that must be switched from clear text to *****?
- How are passwords stored? Can they be stored in clear text, and how do you change this?
User registration
By default, users can sign up themselves with the server. In some environments, this self sign-up might be undesirable. It can be changed by switching off user registration. For more information, see User Registration in the Keycloak documentation.
By default, user email addresses are not verified. This verification must be enabled in production environments. For more information, see c_admin_security.html#GUID-51ae88a1-a9e5-403c-b859-fc0fd4e6e52e__emailsettingskeycloak.
Setting up user roles and access
Provide answers to these questions:
- How do you create and delete users and set their access levels?
- How do you create groups and assign them privileges?
- How do you establish password rules for users (such as no reuse, minimum length, or character requirements, and so on)?
- What are the superuser IDs or IDs with special secuirty privileges?
Single sign-on
By default, Keycloak manages users and passwords locally. In production environments, it is normally appropriate to use single sign-on. For more information, see LDAP user administration.
Administration only accounts
Users in the Administrator group can manage the team space where they can configure licenses and notifications and add a repository to store the System model. For more information, see Team space overview.
Users in the Administrator group can also discover all projects stored on the server (including private ones) and assign themselves and others roles in those projects.
For this reason, users who use the server to perform both administration and non-administration tasks must have two different accounts, one for each purpose. For more information, see Default user administration.
Customize the topic TOC with the headings that you are using in your topic. Be sure the topic title matches the filename you have given your own topic.