External S-TAP requirements

To use External S-TAP with your IBM® Guardium® system, your site must meet the following requirements.

For more information about supported platforms for External S-TAP, see IBM Guardium System Requirements and Supported Platforms.

Use Kubernetes on the Red Hat OpenShift platform to manage containers for External S-TAP. However, you can manually manage Docker containers by using the script that is described in External S-TAP deployment scripts. A load-balancing solution is also required, which can be provided as part of your cloud service provider's Kubernetes services. If your site does not use Kubernetes, Guardium provides a sample script to help you configure your load-balancing solution. For more information, see Load balancer scripts.

Important: The CN that you specify to create the certificate signing request (CSR) for the External S-TAP must match the DNS name to which the clients are connecting. For External S-TAP, the CN is the DNS name for the load balancer. If the client database requires that the DN (Designated Name) match the DNS entry, then all the properties in the CSR (such as CN= or OU=) must also match the DNS entry.

For administrators, you can redirect the clients to the External S-TAP by adjusting the DNS resolution. If you change the DNS resolution, be sure to use the DNS name that is visible to the client (that is, the name of the database server).

The External S-TAP can listen to only one port per container.

External S-TAP supports both unencrypted (plain text) and SSL/TLS-encrypted session flows. Other types of encrypted workflows (such as TDGSS and Oracle Native Encryption) are not supported.

If the External S-TAP container host is an on prem or virtual machine, the host must meet the following requirements:

An x86_64 processor.
Minimum RAM memory 500 MB and 2 GB storage.
Linux® kernel version 3.10 or higher (latest version is recommended).
Iptables 1.4 or higher.
Docker 1.12.16 or higher.
Ability to use UNIX domain sockets.
Important: For on-premises installations, enable pubkey authentication for the user who starts the containers on the host systems. The deployment script calls ssh for the host systems multiple times; pubkey authentication simplifies the process.

You can include persistent volumes for storage to keep External S-TAP information after the Docker or Kubernetes container has exited. To use a persistent volume,

For Kubernetes, configure the storage to appear inside any containers at /persistent. For more information, see Deploy External S-TAP window.
For container_mgmt.sh, use the --persistent flag to specify the name of the Docker volume to use. For more information, see --persistent in External S-TAP deployment scripts.

All installations, either on prem or in the cloud, must meet the following requirements:

For Docker, make sure that the installing user has the necessary privileges to create a container across systems.
Make sure that network access is available to either the Docker store or to a private Docker registry where an admin can push images from the Docker store.
Database clients must be able to use TCP to connect to the External S-TAP host and the External S-TAP host must be able to connect to the database server.
Locate all External S-TAP hosts in the network topology in such a way that they can be placed between the client and database host. Ideally, the latency between the client, the External S-TAP host, and the database service is as brief as possible.
Be sure that access to the External S-TAP host is secured.
Docker uses the kernel core pattern of the host to determine where to place core files. On some systems, the default path is not appropriate from the container's perspective. To make sure that core files are stored correctly, use the following pattern:
```
'/tmp/core.%t.%e.%p'
```
For example, on the External S-TAP host where a container runs, enter the following command to set the core pattern:
```
echo '/tmp/core.%t.%e.%p' | sudo tee /proc/sys/kernel/core_pattern'
```

Microsoft Azure users: The Azure SQL database connection policy is set to Redirect by default. You need to set the policy to Proxy. For more information, see Azure SQL Connectivity Architecture in the Microsoft Azure documentation.

In addition, to connect to the database, you need to update the /etc/hosts file for your system to add the following entry:

<External-IP> <your DB host>

For Windows, add this entry to \windows\system32\drivers\etc\hosts.
For Linux or UNIX, add this entry to /etc/hosts.

AWS Network Load Balancer users: AWS Network Load Balancer does not support listening on multiple public IP addresses, You can't listen twice on the same port for the same IP. Therefore, if your site is using multiple IP addresses, you must use a separate load balancer for each IP address.