Compliance v23
TPA can generate configurations designed to make it easy for a
cluster to comply with the STIG or CIS standards. If you pass
--compliance stig
or --compliance cis
to tpaexec configure
,
TPA will:
- Check that other options are compatible with the appropriate standard.
- Add various entries to the generated
config.yml
, including marking that this is a cluster meant to comply with a particular standard and setting Postgres configuration as required by the standard. - Adjust some deployment tasks to enforce compliance.
- Run checks at the end of deployment.
The deploy-time checks can
be skipped by giving the option --excluded_tasks=compliance
to tpaexec
deploy
. This feature is intended for testing only, when using a test
system on which full compliance is impossible (for example,
because SSL certificates are not available).
There are some situations in which TPA will intentionally fail to comply with the selected standard; these are documented under Exceptions below.
STIG
STIG compliance is indicated by the --compliance stig
option to
tpaexec configure
.
Option compatibility
STIG compliance requires the bare
platform and the epas
flavour.
It requires the RedHat OS with version 8 or 9.
Settings in config.yml
The following entry is added to cluster_vars
to use the SQL/Protect
feature of EDB Postgres Advanced Server:
The following entries are added to cluster_vars
to force clients
to use SSL authentication:
The following entries are added to cluster_vars
to set GUCs in
postgresql.conf:
The following entries are added to postgres_conf_settings
in
cluster_vars
to set GUCs in postgresql.conf:
Deployment differences
During deployment, TPA will set connection limits for the database users it creates, corresponding to the number of connections that are needed for normal operation. As each user is set up, it will also check that an SSL client certificate has been provided for it.
Providing client ssl certificates
STIG requires DOD-approved ssl certificates for client connections.
These certificates can't be generated by TPA and therefore must be
supplied. When setting up authentication for a user from a
node in the cluster, TPA will look for a certificate/key pair on the
node. The certificate and key should be in files called .crt
and .key in the directory given by the ssl_client_cert_dir
setting. The default for this setting is /
, so the files would be,
for example, /barman.crt
and /barman.key
when the barman
user is
being set up.
Final checks
At the end of deployment, TPA will check that the server has FIPS enabled.
Exceptions
If you select EFM as the failover manager, TPA will configure password authentication for the EFM user. This goes against the STIG requirement that all TCP connections use certificate authentication. The reason for this exception is that EFM does not support certificate authentication.
CIS
CIS compliance is indicated by the --compliance cis
option to tpaexec
configure
.
Settings in config.yml
The following entries are added to cluster_vars
to set GUCs in
postgresql.conf:
The following entry is added to cluster_vars
to enable required
extensions:
The following entry is added to cluster_vars
to set the umask for
the postgres OS user:
The following entries are added to postgres_conf_settings
in
cluster_vars
to set GUCs in postgresql.conf:
Final checks
At the end of deployment, TPA will check that the server has FIPS enabled.
Exceptions
TPA does not support pgBackRest as mentioned in the CIS specification. Instead TPA installs Barman.
TPA does not install and configure set_user
as required by the CIS
specification. This is because preventing logon by the Postgres user
would leave TPA unable to connect to, and configure, the database.