Docker image for Verify Access Runtime

Edit online

The Security Verify Access Runtime Docker image provides the Advanced Access Control and Federation capabilities of Security Verify Access.

Consider the following points when you deploy a runtime container:
  • The runtime container relies on a configuration snapshot which has been generated by the Security Verify Access configuration container.
  • The runtime container should be started as the 'isam' user (UID: 6000). In a standard container environment this will happen automatically but in a Kubernetes environment the security context should be set to allow the container to start as this particular user.
  • The runtime_reload command can be used to reload the runtime configuration when the configuration snapshot changes.
  • The following environment variables are used by the container:
    CONFIG_SERVICE_URL
    The URL that will be used to access the published configuration data. If using the configuration service of the Security Verify Access configuration container, the URL would be of the format: https://<container-ip>:<mapped-port>/shared_volume. A BA header will be supplied to handle authentication to the configuration service. If this environment variable is not specified the container will expect the configuration snapshot to be available in the shared configuration volume, at /var/shared/snapshots.
    CONFIG_SERVICE_USER_NAME
    The name of the user that will be used when accessing the configuration service.
    CONFIG_SERVICE_USER_PWD
    The password for the user that will be used when accessing the configuration service.
    CONFIG_SERVICE_TLS_CACERT
    The CA certificate bundle that is used to verify connection to the configuration snapshot service. Valid values for this property are:
    file:<file.pem>
    The file prefix and the path to a PEM formatted certificate bundle. For example: file:/path/to/ca.pem
    disable
    Disable certificate verification for the configuration service.
    operator
    Use the Kubernetes service account CA certificate that the Kubernetes/OpenShift PKI infrastructure provides. The service account must have permission to read secrets in the namespace that the Verify Access container is deployed to.
    CONTAINER_TIMEZONE
    The time zone that is used by the container. For example: "Australia/Brisbane".
    HTTP_PORT
    The port on which the container will listen for HTTP request (default: 9080).
    Note: If the port number is less than 1024, the NET_BIND_SERVICE capability is required for the container.
    HTTPS_PORT
    The port on which the container will listen for HTTPS request (default: 9443).
    Note: If the port number is less than 1024, the NET_BIND_SERVICE capability is required for the container.
    SNAPSHOT
    The name of the configuration data snapshot file that is to be used when starting the container. No path information should be included in the filename. The standard snapshot locations will be searched for the specified snapshot file. This variable, if not specified, will default to the latest published configuration.
    SNAPSHOT_ID
    The identifier of the snapshot that is used by the container. The full snapshot name is constructed as:
    ‘isva_<product_version>_<snapshot_id>.snapshot’
    If no identifier is specified, an identifier of 'published' is used. If a full snapshot name is specified by using the SNAPSHOT environment variable, this variable is ignored.
    Note: This environment variable is not available before version 10.0.3.0.
    CONFIG_SNAPSHOT_SECRETS
    The ordered list of secrets that is used to encrypt the configuration snapshot file. The list of secrets is separated by the || (two pipe) characters. Each secret must be longer than 16 characters. If more than one secret is defined, the first secret in the list is used to encrypt the configuration snapshot file. Every secret in the list is tried to decrypt the configuration snapshot file. If the configuration snapshot cannot be decrypted, the container fails to bootstrap. If no configuration snapshot secrets are defined, the configuration snapshot file is not encrypted.
    Note: If the secret that is used to encrypt a snapshot is lost, the snapshot cannot be recovered.
    WLP_LOGGING_CONSOLE_FORMAT
    The required format for the log messages. Valid values are simple or json format (default: json)
    WLP_LOGGING_CONSOLE_SOURCE
    The list of comma-separated sources that route to the console. This property applies only when the console format is JSON. Valid values are message, trace, accessLog, ffdc, and audit (default: message).
    WLP_LOGGING_CONSOLE_LOGLEVEL
    This filter controls the granularity of messages that go to the console. The valid values are INFO, AUDIT, WARNING, ERROR, and OFF (default: AUDIT).
    LANG
    The language in which messages which are sent to the console will be displayed. If no language is specified the messages will appear in English. The following table lists the supported languages:
    Language Environment Variable Value
    Czech cs_CZ.utf8
    German de_DE.utf8
    Spanish es_ES.utf8
    French fr_FR.utf8
    Hungarian hu_HU.utf8
    Italian it_IT.utf8
    Japanese ja_JP.utf8
    Korean ko_KR.utf8
    Polish pl_PL.utf8
    Portuguese (Brazil) pt_BR.utf8
    Russian ru_RU.utf8
    Chinese (Simplified) zh_CN.utf8
    Chinese (Traditional) zh_TW.utf8
    FIXPACKS
    A space-separated ordered list of fix packs to be applied when starting the container. If this environment variable is not present, and the CONFIG_SERVICE_URL environment has not been set, any fix packs present in the fixpacks directory of the configuration volume will be applied in alphanumeric order.

Configuration

Edit online
All configuration activities must be completed using the main Security Verify Access image, running as a configuration container. The configuration container supports a scaled-down version of the Security Verify Access appliance LMI. You can use this LMI to manage the configuration data.
Note: To make a configuration available to the runtime container, you must click Publish configuration in the LMI.

Service

Edit online

The container, by default, will listen for incoming requests on port 9443, and optionally port 9080 (if HTTP access has been enabled in the configuration snapshot). Use the HTTPS_PORT and HTTP_PORT environment variables to change the ports on which the container will listen.

Note: If the runtime container is exposed on an external IP address there must be network restrictions in place to ensure that access is not allowed from untrusted clients, or the runtime must be configured to require mutual TLS authentication.

Shared configuration data

Edit online

The shared configuration volume is a section of the file system that is reserved for the storage of persistent data.

The shared configuration volume is available in a Security Verify Access runtime container at '/var/shared'.

The shared configuration volume is used to store the following data:
Snapshots
Configuration snapshots are retrieved from the 'snapshots' sub-directory of the shared configuration volume if the CONFIG_SERVICE_URL environment variable is not specified.

The configuration data which is used by the Security Verify Access image is fully compatible with the configuration data used by the legacy Security Verify Access image.

Fixpacks
Fix packs are retrieved from the ‘fixpacks’ sub-directory of the shared configuration volume if the CONFIG_SERVICE_URL environment variable is not specified.

When a runtime container is started, fix packs that are specified in the FIXPACKS environment variable will be applied in the order that they are specified. If the FIXPACKS environment variable is not present, and the CONFIG_SERVICE_URL environment variable has not been specified, any fix packs present in the 'fixpacks' directory of the configuration volume will be applied in alphanumeric order. If the CONFIG_SERVICE_URL environment variable has been specified the required 'fixpacks' must be specified using the FIXPACKS environment variable.

Logging

Edit online

The logging and auditing of the runtime will,by default,be sent to the console of the container, in JSON format. This allows the logging infrastructure of the container environment itself to manage the auditing and message logs.

Some additional log files will however still be generated on the disk of the container. By default, Docker uses a layered file system to help reduce the disk space utilization of the containers. However, this file system has slower write speeds than standard file systems. As such, a standard Docker practice is to place any files that are updated frequently (for example, log files) on a shared volume. All of the log files that are written by the container are located in the '/var/application.logs.' directory. Therefore, the recommended approach is to create this directory as a shared volume when you create your container.
Note: Multiple containers should not reference the same persistent volume for log storage, otherwise multiple containers will attempt to write to the same log file at the same time, causing data write and integrity issues. In a Kubernetes environment this problem can be overcome by deploying the containers in a StatefulSet (refer to the official Kubernetes documentation for information on StatefulSets).
The log file directory structure is shown in the following table.
Table 1. Logs directory structure
Log file Sub-directory (relative to the root log directory)
Runtime server log files rtprofile
Database server log files db