Recommendations

Default tenant at bootstrapping

Configuring a default id is mandatory. Configuring a default tenant name for the initial setup is also highly recommended. When starting MACMA the new tenant will be created including an admin user.

Restarting with different default tenant or admin user is not supported. Use a clean environment instead and start with the desired variables.

MACMA will not bootstrap if:

values for tenant id and name are not provided
the provided tenant does not exist but an existing tenant has MACMA application on startup (this indicates bootstrapping happened before)

SAML Support

MACMA does not support SAML. For this reason avoid to configure realms and clients that support SAML in Keycloak. Reasoning: SAML is based on XML and XXE is one of the most important threats according to OWASP.

Session ID Disclosure

When in Keycloak the log level is set to DEBUG, the session ID will be logged on login and logout. Avoid this session ID disclosure by using less verbose log levels like WARN or INFO but never DEBUG in a productive environment.

Host Hardening

The Center for Internet Security (CIS) provides a detailed list of recommendations regarding the usage of docker in production. Those recommendations should be applied to the docker host on which MACMA containers will run. The proper implementation of those recommendations should be checked with corresponding tooling (e.g. docker-bench). It’s a matter of great importance to apply the described security hardening in order to ensure a secure usage of MACMA.

Data security

Depending on the module version, data in transit and rest is not encrypted. Please check known_limitations

MACMA does not encrypt any communication between client and application itself by default. The server certificates need to be handled in the Nexeed IAS Gateway. Keep in mind that the browser being used needs to trust the given CA as well in order to be able to communicate with MACMA.

TLS can be disabled by configuration. Do not consider this for production purposes.

Service meshes

Service meshes are state-of-the-art technology to secure all communication within and between Kubernetes clusters. They typically intercept and redirect traffic to/from the Pods using proxy containers injected into the application Pods. These proxies can then secure communication between Pods using mTLS. In such scenarios, the service mesh control plane manages the complex and error-prone certificate management for the various mTLS connections, while being transparent to the actual application workloads.

The installation and configuration of a service mesh is the responsibility of the cluster operator and is not part of the NEXEED IAS installation process. However, it is recommended to use service meshes to secure all communication between MACMA services and NEXEED IAS modules running in the same cluster.

Database connection encryption

MACMA does not encrypt the database connection by default since this is highly database-specific. Depending on the database being used, the following adaptations are highly recommended:

MsSql

# Setting environment variables for TLS connection to databases
NEXEED_MACMA_KEYCLOAK_DATABASE_JDBC_PARAMS="encrypt=true;trustServerCertificate=false;"
NEXEED_MACMA_MASTER_DATA_DATASOURCE_URL="jdbc:sqlserver://<host>:<port>;databaseName=<database-name>;encrypt=true;trustServerCertificate=false;"

Keycloak DB connection pool background validation interval

The underlying Keycloak connection pool supports configuring the interval between liveness checks of idle DB connections. Lower values mean faster recovery in case of connection loss - but also mean higher load.

The environment variable that needs to be configured for Keycloak is DB_BG_VALIDATION_DURATION and defaults to 55 seconds (55S).

Restrict access to Keycloak Administrative UI

It is highly recommended that access to Keycloak administration UI (https://<BASE_URL><CONTEXT_PATH>/auth/admin) is limited to dedicated systems or local access.