Security Configuration¶

Kinetica comes equipped with several configuration options and some software to help secure and protect your data. Currently, there are several paths to securing the database in some fashion:

HTTPD -- Hides internal ports
HTTPD with SSL -- Hides internal ports and secures connections
HTTPD with External Authentication -- Hides internal ports and enables & configures external authentication
HTTPD with SSL and External Authentication -- Hides internal ports, secures connections, and enables & configures external authentication
- LDAP
- Microsoft Active Directory
- Kerberos

Prerequisites¶

Before configuring your Kinetica cluster using the sections below, the following requirements should be met:

If using an external authentication system, ensure it is running
Ensure GAdmin has been initialized per the instructions found in Validate Kinetica and the default username and password have been updated
Stop host manager using:
```
service gpudb_host_manager stop
```
Update your firewall settings to allow HTTPD passthrough (i.e. 8082, 8443, 8444) and to disable inbound connections to all other ports. See either Adjust the Firewall (RHEL) or Adjust the Firewall (Debian/Ubuntu) for more information
Update the database configuration file (/opt/gpudb/core/etc/gpudb.conf) for the following:
1. Update the following settings, using the table below as a guide:
```
# Require authentication.
require_authentication = true

# Enable authorization checks.
enable_authorization = true
```
2. Optionally, update the http_allow_origin setting. The default value for this setting (*) allows access from all domains. This setting controls which domains outside of your Kinetica cluster that can access the database, e.g., if you only wanted to allow access to the database from http://myapp.com, update the setting to http_allow_origin = http://myapp.com (comma-separated for multiple domains)
```
http_allow_origin = <domain1>,<domain2>
```

Authentication/Authorization Scenarios¶

Configuration Type	require_authentication	enable_authorization	Description
No auth	`false`	`false`	All users will be logged in as anonymous and have no restrictions (default)
Authenticated	`true`	`false`	All users are required to have an account to login and will be given Admin role privileges upon logging in
Authorized	`false`	`true`	Users with an account will be given their designated roles. Users without an account will be given Public role privileges
Authenticated / Authorized	`true`	`true`	All users are required to have an account to login and will be given their designated roles. No guest account access available.

HTTPD¶

This section outlines how to configure the database to use the packaged Apache HTTPD proxy solution.

Database Configuration¶

In /opt/gpudb/core/etc/gpudb.conf:

Update the following setting to true to enable an HTTPD proxy:
```
enable_httpd_proxy = true
```

ODBC Configuration¶

Important

Depending on how you installed ODBC, there may be other odbc.ini files available on your system that could override Kinetica's System DSNs. Kinetica's System DSNs are located in /opt/gpudb/connectors/odbcserver/client/etc/odbc.ini

In /opt/gpudb/connectors/odbcserver/bin/gpudbodbc.ini:

Update the URL, ensuring the host is correct for your setup:
```
URL=http://<hostname>:8082/gpudb-0
```
Optionally, update the UID and PWD settings. If require_authentication is false and enable_authorization is true, add credentials for a guest account role with different permissions than the Public role. If both require_authentication and enable_authorization are true, add credentials to enable a guest account. Note there has to be an account that matches the given UID and PWD settings:
```
UID=
PWD=
```

Important

Leave the UID and PWD settings blank to ensure a completely secure setup.

Verification¶

Restart host manager and the database using:

service gpudb_host_manager start
service gpudb start

Run a Host Manager status check:
```
service gpudb_host_manager status
```

Verify the output shows HTTPD is running:

...
Httpd            : Running (14250 14277 14278 14279 14280 14282)
...

Ensure HTTPD is working:
```
curl <hostname>:8082
```
Ensure Kinetica is running properly:
```
curl <hostname>:8082/gpudb-0
```

HTTPD + SSL¶

This section outlines how to configure the database to use the packaged Apache HTTPD proxy solution with SSL.

General Configuration¶

Ensure a valid SSL key and certificate have been created. It is recommended you create them in /opt/gpudb/certs

Ensure the SSL certificate has been added to OpenSSL's trust store:

ln -s <path/to/cert.pem> `openssl x509 -hash -noout -in <path/to/cert.pem>`.0

Import an SSL certificate into a Java truststore using the following command:

keytool -import -trustcacerts -file <path/to/cert/file> -alias cert_alias -keystore <desired/path/for/keystore.jks>

Database Configuration¶

In /opt/gpudb/core/etc/gpudb.conf:

Update the following setting to true to enable an HTTPD proxy:
```
enable_httpd_proxy = true
```
Update the following setting to true to force HTTPD to use HTTPS:
```
httpd_proxy_use_https = true
```

ODBC Configuration¶

Important

Depending on how you installed ODBC, there may be other odbc.ini files available on your system that could override Kinetica's System DSNs. Kinetica's System DSNs are located in /opt/gpudb/connectors/odbcserver/client/etc/odbc.ini

Navigate to the proper odbc.ini file and update the following settings (for all DSNs)
```
SSLCACertFile=<path/to/cert/file>
UseSsl=1
```
Optionally, add the following settings. Read more about the settings in the ODBC client configuration section:
```
AllowHostMismatch=1
AllowSelfSignedCert=1
AllowExpiredCert=1
```
Navigate to /opt/gpudb/connectors/odbcserver/bin/gpudbodbc.ini and update the following settings, ensuring you replace the SslCertfile and SslKeyFile setting values with the proper file paths to the ODBC server's private key and private certificate respectively:
```
UseSsl=1
SslCertfile=<path/to/cert/file>
SslKeyFile=<path/to/key/file>
```
Update the URL, adding https and ensuring the host is correct for your setup
```
URL=https://<hostname>:8082/gpudb-0
```
Optionally, update the CertPath setting if your SSL certificate and key are not in the default location:
```
CertPath=/opt/gpudb/certs
```
Optionally, change the SslAllowHostMismatch setting to 1 if you don't want to enforce host matching when using SSL between ODBC and Kinetica:
```
SslAllowHostMismatch=0
```
Optionally, update the UID and PWD settings. If require_authentication is false and enable_authorization is true, add credentials for a guest account role with different permissions than the Public role. If both require_authentication and enable_authorization are true, add credentials to enable a guest account. Note there has to be an account that matches the given UID and PWD settings:
```
UID=
PWD=
```

Important

Leave the UID and PWD settings blank to ensure a completely secure setup.

HTTPD "Data" Configuration¶

Navigate to /opt/gpudb/httpd/conf/data.conf and uncomment the following settings, ensuring you replace the SSLCertificateFile and SSLCertificateKeyFile setting values with the proper file paths. Read the Apache HTTPD SSL Docs for more information
```
SSLEngine On
...
SSLCertificateFile </path/to/cert>
SSLCertificateKeyFile </path/to/key>
SSLProxyEngine On
RequestHeader set X-Forwarded-Proto "https"
```

Important

The following settings are optional but provide greater security. Depending on what version of OpenSSL is installed on the system, the TLS version should be updated. The SSLCipherSuite setting can also be upgraded, e.g., SSLCipherSuite HIGH:!aNULL:!MD5:

SSLProtocol -all +TLSv1.1
SSLCipherSuite HIGH:MEDIUM
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Header set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header set Access-Control-Max-Age "1000"
Header set Access-Control-Allow-Headers "x-requested-with, Content-Type, origin, authorization, accept, client-security-token"

HTTPD "NoAuth" Configuration¶

Navigate to /opt/gpudb/httpd/conf/noauth.conf and uncomment the following settings, ensuring you replace the SSLCertificateFile and SSLCertificateKeyFile setting values with the proper file paths. Read the Apache HTTPD SSL Docs for more information
```
SSLEngine On
...
SSLCertificateFile </path/to/cert>
SSLCertificateKeyFile </path/to/key>
SSLProxyEngine On
RequestHeader set X-Forwarded-Proto "https"
```

Important

The following settings are optional but provide greater security. Depending on what version of OpenSSL is installed on the system, the TLS version should be updated. The SSLCipherSuite setting can also be upgraded, e.g., SSLCipherSuite HIGH:!aNULL:!MD5:

SSLProtocol -all +TLSv1.1
SSLCipherSuite HIGH:MEDIUM
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

Kinetica Components Configuration¶

Reveal¶

Navigate to /opt/gpudb/connectors/reveal/etc/default.json and update the url setting:
```
"gadmin": {
  "url": "https://localhost:8443/gadmin"
},
```

GAdmin¶

Navigate to the /opt/gpudb/tomcat/webapps/gadmin/js/settings.js file and update the PORT variable to the secured Reveal port (default is 8444):
```
var REVEAL = {
  PORT: '8444',
  ...
```
Navigate to the /opt/gpudb/tomcat/webapps/gadmin/WEB-INF/classes/gaia.properties file and update the following settings for https, ensuring the host is correct for your setup
```
gpudb_ext_url = https://<hostname>:8082/gpudb-0

...
gpudb_ext_hm_url = https://<hostname>:8082/gpudb-host-manager
```
Update the kisql_ca_cert_path setting for the filepath to the SSL certificate:
```
kisql_ca_cert_path = </file/path/to/ssl-cert>
```
Navigate to the /opt/gpudb/tomcat/conf/catalina.properties file and add the following settings to the bottom of the file, ensuring you replace the trustStore setting value with the proper file path and the trustStorePassword setting with the correct password
```
javax.net.ssl.trustStore=</path/to/keystore>
javax.net.ssl.trustStorePassword=<your-keystore-password>
```

Important

A keystore being added to catalina.properties will prevent security settings from being overwritten during a Kinetica upgrade

Verification¶

Restart host manager and the database using:

service gpudb_host_manager start
service gpudb start

Run a Host Manager status check:
```
service gpudb_host_manager status
```

Verify the output shows HTTPD is running:

...
Httpd            : Running (14250 14277 14278 14279 14280 14282)
...

Ensure Kinetica is running properly:

curl -k https://<hostname>:8082/gpudb-0

Verify the output shows Kinetica is running:
```
Kinetica is running!
```
Login to GAdmin at https://<hostname>:8443
Login to Reveal at https://<hostname>:8444

HTTPD + External Authentication¶

This section outlines how to configure the database to use an external authentication source with the packaged Apache HTTPD proxy solution.

Database Configuration¶

In /opt/gpudb/core/etc/gpudb.conf:

Update the following setting to true to enable an HTTPD proxy:
```
enable_httpd_proxy = true
```

Update the following settings to true:

# IMPORTANT: DO NOT ENABLE unless external access to GPUdb ports
# has been blocked via firewall AND the authentication proxy is
# configured to block REMOTE_USER HTTP headers passed in from clients.
enable_external_authentication = true

# Automatically create accounts for externally-authenticated users.
# If enable_external_authentication is false, this setting has no effect.
# Note that accounts are not automatically deleted if users are removed
# from the external authentication provider and will be orphaned.
auto_create_external_users = true

ODBC Configuration¶

Important

Depending on how you installed ODBC, there may be other odbc.ini files available on your system that could override Kinetica's System DSNs. Kinetica's System DSNs are located in /opt/gpudb/connectors/odbcserver/client/etc/odbc.ini

In /opt/gpudb/connectors/odbcserver/bin/gpudbodbc.ini:

Update the URL, ensuring the host is correct for your setup:
```
URL=http://<hostname>:8082/gpudb-0
```
Optionally, update the UID and PWD settings. If require_authentication is false and enable_authorization is true, add credentials for a guest account role with different permissions than the Public role. If both require_authentication and enable_authorization are true, add credentials to enable a guest account. Note there has to be an account that matches the given UID and PWD settings:
```
UID=
PWD=
```

Important

Leave the UID and PWD settings blank to ensure a completely secure setup.

External Authentication Configuration¶

External authentication data store integration with Kinetica is accomplished through an Apache HTTPD proxy. This proxy comes packaged with Kinetica and can be found in /opt/gpudb/httpd. Since this portion is controlled by Apache HTTP not Kinetica, see the Apache documentation for further details. External authentication can be configured for Kinetica with or without SSL.

Kinetica currently supports the following external authentication sources:

LDAP
Microsoft Active Directory
Kerberos

Note

For testing purposes, Kinetica is packaged with an OpenLDAP server daemon (slapd) that already includes several sample users. It can be started & initialized manually, using the commands:

$ sudo /opt/gpudb/httpd/gpudb-openldap.sh start
$ /opt/gpudb/httpd/openldap/openldap-init.sh

Note

Only run /opt/gpudb/httpd/openldap/openldap-init.sh the first time the included OpenLDAP instance is started.

LDAP¶

Before making configuration changes, ensure host manager is stopped:
```
service gpudb_host_manager stop
```

Navigate to /opt/gpudb/httpd/conf/data.conf, uncomment the following settings, and update them as necessary. Read more about the HTTPD LDAP settings in the Apache HTTPD LDAP documentation:

# Clear the REMOTE_USER and KINETICA_ROLES headers, so that they
# cannot be passed through by the client.
Header unset REMOTE_USER
Header unset KINETICA_ROLES

## The following is an example configuration for authenticating Kinetica
## users against an LDAP server. Please refer to the Apache httpd
## configuration manual for assistance. Note that in order to use LDAP
## authentication, enable_external_authentication must be set to true in
## gpudb.conf.
AuthName "Kinetica Authentication"

## LDAP server URL and full LDAP path to users directory with search
## parameters. If an attribute other than "uid" is used for the user ID,
## update it below.
AuthLDAPUrl ldap://<ldap-hostname:ldap-port>/dc=gpudb,dc=com?uid?sub

## Valid LDAP user to use for search during bind
AuthLDAPBindDN cn=admin,dc=gpudb,dc=com
## Password of user for search during bind
AuthLDAPBindPassword admin

AuthType Basic
## The following (AuthBasicAllowAnonymous) is a custom httpd configuration
## parameter which will allow failed LDAP lookups to trickle through to
## GPUdb, where it can attempt an internal authentication and/or reach
## endpoints without credentials if auth is not required.  This can be
## turned off when internal users are not being used, and no anonymous
## access is desired.
AuthBasicAllowAnonymous on
AuthBasicProvider ldap
AuthzLDAPAuthoritative on

## To attempt authentication, uncomment the following
## <LimitExcept>..</LimitExcept> block.  Once authentication is enabled,
## you can also limit access to gpudb and translate LDAP groups to
## Kinetica Roles...
##
## To prevent users outside certain LDAP groups from accessing the
## system, uncomment the <RequireAny> block within the <LimitExcept>
## block below, and list each accepted LDAP group, one per
## Require ldap-group entry, in the format:
##
##     <RequireAny>
##         Require ldap-group <ldap-group1-cn>
##         ...
##         Require ldap-group <ldap-groupN-cn>
##     </RequireAny>
##
## If membership in all groups is required, rather than any one of the
## groups, change the RequireAny tags to RequireAll tags.
##
## To translate membership in LDAP groups to membership in Kinetica
## roles, uncomment the <RequireAll> block within the <LimitExcept>
## block below, and replace the example mappings with mappings in the
## format:
##
##     <RequireAll>
##         Require kinetica-ldap-role-mapping <kinetica-role1-to-grant> <ldap-group1-cn>
##         ...
##         Require kinetica-ldap-role-mapping <kinetica-roleN-to-grant> <ldap-groupN-cn>
##     </RequireAll>
##
## Note that access is not restricted to users in these groups (use
## Require ldap-group, demonstrated above, to enforce group
## restrictions). Also note that enable_authorization,
## auto_grant_external_roles and potentially auto_revoke_external_roles
## must be set to true in gpudb.conf to enable role mappings.

<LimitExcept OPTIONS>
    <RequireAll>
        #<RequireAny>
        #    Require ldap-group cn=group1,dc=gpudb,dc=com
        #    Require ldap-group cn=group2,dc=gpudb,dc=com
        #</RequireAny>
        <RequireAny>
            #<RequireAll>
            #    Require kinetica-ldap-role-mapping kinetica-role-1 cn=group1,dc=gpudb,dc=com
            #    Require kinetica-ldap-role-mapping kinetica-role-2 cn=group2,dc=gpudb,dc=com
            #</RequireAll>
            Require valid-user
        </RequireAny>
    </RequireAll>
</LimitExcept>

...

## Add REMOTE_USER and KINETICA_ROLES HTTP headers, and do not pass
## through any AUTHORIZATION header containing LDAP credentials. Update
## the first line below if an attribute other than "uid" is used for the
## user ID.
RequestHeader set REMOTE_USER %{AUTHENTICATE_samacccountname}e env=AUTHENTICATE_samaccountname
RequestHeader set KINETICA_ROLES %{KINETICA_ROLES}e env=KINETICA_ROLES
RequestHeader unset AUTHORIZATION env=REMOTE_USER

Important

If you have groups you want to map to Kinetica roles, edit the LimitExcept tag, noted above.

Important

If using Apache HTTPD version 2.2, the LimitExcept configuration can be simplified to this:

<LimitExcept OPTIONS>
    Require valid-user
</LimitExcept>

The LDAP group mapping should also follow HTTPD 2.2 styling, as follows:

## To map LDAP groups to Kinetica roles, add the mappings here. Note
## that access is not restricted to users in these groups (use Require
## ldap-group to enforce group restrictions). Also note that
## auto_grant_external_roles must be set to true in gpudb.conf to
## enable role mappings.
Require kinetica-ldap-role-mapping role1 cn=group1,dc=gpudb,dc=com
Require kinetica-ldap-role-mapping role2 cn=group2,dc=gpudb,dc=com

Microsoft Active Directory¶

Before making configuration changes, ensure host manager is stopped:
```
service gpudb_host_manager stop
```

Navigate to /opt/gpudb/httpd/conf/data.conf, uncomment the following settings, and update them as necessary, ensuring you replace any instances of uid with samaccountname:

# Clear the REMOTE_USER and KINETICA_ROLES headers, so that they
# cannot be passed through by the client.
Header unset REMOTE_USER
Header unset KINETICA_ROLES

## The following is an example configuration for authenticating Kinetica
## users against an LDAP server. Please refer to the Apache httpd
## configuration manual for assistance. Note that in order to use LDAP
## authentication, enable_external_authentication must be set to true in
## gpudb.conf.
AuthName "Kinetica Authentication"

## LDAP server URL and full LDAP path to users directory with search
## parameters. If an attribute other than "uid" is used for the user ID,
## update it below.
AuthLDAPUrl ldap://127.0.0.1:9009/dc=gpudb,dc=com?samaccountname?sub

## Valid LDAP user to use for search during bind
AuthLDAPBindDN cn=admin,dc=gpudb,dc=com
## Password of user for search during bind
AuthLDAPBindPassword admin

AuthType Basic
## The following (AuthBasicAllowAnonymous) is a custom httpd configuration
## parameter which will allow failed LDAP lookups to trickle through to
## GPUdb, where it can attempt an internal authentication and/or reach
## endpoints without credentials if auth is not required.  This can be
## turned off when internal users are not being used, and no anonymous
## access is desired.
AuthBasicAllowAnonymous on
AuthBasicProvider ldap
AuthzLDAPAuthoritative on

## To attempt authentication, uncomment the following
## <LimitExcept>..</LimitExcept> block.  Once authentication is enabled,
## you can also limit access to gpudb and translate LDAP groups to
## Kinetica Roles...
##
## To prevent users outside certain LDAP groups from accessing the
## system, uncomment the <RequireAny> block within the <LimitExcept>
## block below, and list each accepted LDAP group, one per
## Require ldap-group entry, in the format:
##
##     <RequireAny>
##         Require ldap-group <ldap-group1-cn>
##         ...
##         Require ldap-group <ldap-groupN-cn>
##     </RequireAny>
##
## If membership in all groups is required, rather than any one of the
## groups, change the RequireAny tags to RequireAll tags.
##
## To translate membership in LDAP groups to membership in Kinetica
## roles, uncomment the <RequireAll> block within the <LimitExcept>
## block below, and replace the example mappings with mappings in the
## format:
##
##     <RequireAll>
##         Require kinetica-ldap-role-mapping <kinetica-role1-to-grant> <ldap-group1-cn>
##         ...
##         Require kinetica-ldap-role-mapping <kinetica-roleN-to-grant> <ldap-groupN-cn>
##     </RequireAll>
##
## Note that access is not restricted to users in these groups (use
## Require ldap-group, demonstrated above, to enforce group
## restrictions). Also note that enable_authorization,
## auto_grant_external_roles and potentially auto_revoke_external_roles
## must be set to true in gpudb.conf to enable role mappings.

<LimitExcept OPTIONS>
    <RequireAll>
        #<RequireAny>
        #    Require ldap-group cn=group1,dc=gpudb,dc=com
        #    Require ldap-group cn=group2,dc=gpudb,dc=com
        #</RequireAny>
        <RequireAny>
            #<RequireAll>
            #    Require kinetica-ldap-role-mapping kinetica-role-1 cn=group1,dc=gpudb,dc=com
            #    Require kinetica-ldap-role-mapping kinetica-role-2 cn=group2,dc=gpudb,dc=com
            #</RequireAll>
            Require valid-user
        </RequireAny>
    </RequireAll>
</LimitExcept>

...

## Add REMOTE_USER and KINETICA_ROLES HTTP headers, and do not pass
## through any AUTHORIZATION header containing LDAP credentials. Update
## the first line below if an attribute other than "uid" is used for the
## user ID.
RequestHeader set REMOTE_USER %{AUTHENTICATE_samacccountname}e env=AUTHENTICATE_samaccountname
RequestHeader set KINETICA_ROLES %{KINETICA_ROLES}e env=KINETICA_ROLES
RequestHeader unset AUTHORIZATION env=REMOTE_USER

Important

If you have groups you want to map to Kinetica roles, edit the LimitExcept tag, noted above.

Important

If using Apache HTTPD version 2.2, the LimitExcept configuration can be simplified to this:

<LimitExcept OPTIONS>
    Require valid-user
</LimitExcept>

The LDAP group mapping should also follow HTTPD 2.2 styling, as follows:

## To map LDAP groups to Kinetica roles, add the mappings here. Note
## that access is not restricted to users in these groups (use Require
## ldap-group to enforce group restrictions). Also note that
## auto_grant_external_roles must be set to true in gpudb.conf to
## enable role mappings.
Require kinetica-ldap-role-mapping role1 cn=group1,dc=gpudb,dc=com
Require kinetica-ldap-role-mapping role2 cn=group2,dc=gpudb,dc=com

Kerberos¶

Before making configuration changes, ensure host manager is stopped:
```
service gpudb_host_manager stop
```

Navigate to /opt/gpudb/httpd/conf/data.conf, uncomment the following settings, and update them as necessary:

# Clear the REMOTE_USER and KINETICA_ROLES headers, so that they
# cannot be passed through by the client.
Header unset REMOTE_USER
Header unset KINETICA_ROLES

## The following is an example configuration for authenticating Kinetica
## users against an LDAP server. Please refer to the Apache httpd
## configuration manual for assistance. Note that in order to use LDAP
## authentication, enable_external_authentication must be set to true in
## gpudb.conf.
AuthName "Kinetica Authentication"

Add the following settings below the settings you just uncommented, ensuring you replace the Kerberos realm and service name as well as the path to the keytab file with the appropriate values:

Allow from ALL
AuthType Kerberos
KrbAuthRealms <kerberos-realm-name>
KrbServiceName <kerberos-service-name>
Krb5Keytab </path/to/file.keytab>
KrbMethodNegotiate On
KrbMethodK5Passwd On
KrbVerifyKDC Off
KrbLocalUserMapping On
Require valid-user
RequestHeader set REMOTE_USER %{REMOTE_USER}s
RequestHeader unset AUTHORIZATION env=REMOTE_USER

Navigate to /opt/gpudb/httpd/conf/httpd.conf and add the following line to the end of the file:
```
LoadModule auth_kerb_module /opt/gpudb/httpd/modules/mod_auth_kerb.so
```

User Management¶

Once Kinetica is connected to an external authentication source, the external users can be used for all Kinetica administration. First, a user with administrative permissions that can be tied to an external user will need to be created within Kinetica:

Log into Kinetica Administration Application (GAdmin) with an internal Kinetica administration account
From the Security menu, select Users
Click the New button
For Authentication, select External
Enter an external user's username, preceded by @. This marks the user as an externally authenticated user
For System Level Permission, select System Admin

Note

Although external users are created with the username @<username>, they will log in with their regular username, without the @.

Verification¶

Restart host manager and the database using:

service gpudb_host_manager start
service gpudb start

Run a Host Manager status check:
```
service gpudb_host_manager status
```

Verify the output shows HTTPD is running:

...
Httpd            : Running (14250 14277 14278 14279 14280 14282)
...

Ensure HTTPD is working:
```
curl <hostname>:8082
```
Ensure Kinetica is running properly:
```
curl <hostname>:8082/gpudb-0
```
Verify both internal and external users can login to GAdmin at http://<hostname>:8080
Verify both internal and external users can login to Reveal at http://<hostname>:8088

HTTPD + SSL + External Authentication¶

This section outlines how to configure the database to use an external authentication source with the packaged Apache HTTPD proxy solution and SSL.

Database Configuration¶

In /opt/gpudb/core/etc/gpudb.conf:

Update the following setting to true to enable an HTTPD proxy:
```
enable_httpd_proxy = true
```
Update the following setting to true:
```
httpd_proxy_use_https = true
```

Update the following settings to true:

# IMPORTANT: DO NOT ENABLE unless external access to GPUdb ports
# has been blocked via firewall AND the authentication proxy is
# configured to block REMOTE_USER HTTP headers passed in from clients.
enable_external_authentication = true

# Automatically create accounts for externally-authenticated users.
# If enable_external_authentication is false, this setting has no effect.
# Note that accounts are not automatically deleted if users are removed
# from the external authentication provider and will be orphaned.
auto_create_external_users = true

ODBC Configuration¶

Important

Depending on how you installed ODBC, there may be other odbc.ini files available on your system that could override Kinetica's System DSNs. Kinetica's System DSNs are located in /opt/gpudb/connectors/odbcserver/client/etc/odbc.ini

Navigate to the proper odbc.ini file and update the following settings (for all DSNs)
```
SSLCACertFile=<path/to/cert/file>
UseSsl=1
```
Optionally, add the following settings. Read more about the settings in the ODBC client configuration section:
```
AllowHostMismatch=1
AllowSelfSignedCert=1
AllowExpiredCert=1
```
Navigate to /opt/gpudb/connectors/odbcserver/bin/gpudbodbc.ini and update the following settings, ensuring you replace the SslCertfile and SslKeyFile setting values with the proper file paths to the ODBC server's private key and private certificate respectively:
```
UseSsl=1
SslCertfile=<path/to/cert/file>
SslKeyFile=<path/to/key/file>
```
Update the URL, adding https and ensuring the host is correct for your setup
```
URL=https://<hostname>:8082/gpudb-0
```
Optionally, update the CertPath setting if your SSL certificate and key are not in the default location:
```
CertPath=/opt/gpudb/certs
```
Optionally, change the SslAllowHostMismatch setting to 1 if you don't want to enforce host matching when using SSL between ODBC and Kinetica:
```
SslAllowHostMismatch=0
```
Optionally, update the UID and PWD settings. If require_authentication is false and enable_authorization is true, add credentials for a guest account role with different permissions than the Public role. If both require_authentication and enable_authorization are true, add credentials to enable a guest account. Note there has to be an account that matches the given UID and PWD settings:
```
UID=
PWD=
```

Important

Leave the UID and PWD settings blank to ensure a completely secure setup.

HTTPD "Data" Configuration¶

Navigate to /opt/gpudb/httpd/conf/data.conf and uncomment the following settings, ensuring you replace the SSLCertificateFile and SSLCertificateKeyFile setting values with the proper file paths. Read the Apache HTTPD SSL Docs for more information
```
SSLEngine On
...
SSLCertificateFile </path/to/cert>
SSLCertificateKeyFile </path/to/key>
SSLProxyEngine On
RequestHeader set X-Forwarded-Proto "https"
```

Important

The following settings are optional but provide greater security. Depending on what version of OpenSSL is installed on the system, the TLS version should be updated. The SSLCipherSuite setting can also be upgraded, e.g., SSLCipherSuite HIGH:!aNULL:!MD5:

SSLProtocol -all +TLSv1.1
SSLCipherSuite HIGH:MEDIUM
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure
Header set Access-Control-Allow-Methods "POST, GET, OPTIONS, DELETE, PUT"
Header set Access-Control-Max-Age "1000"
Header set Access-Control-Allow-Headers "x-requested-with, Content-Type, origin, authorization, accept, client-security-token"

HTTPD "NoAuth" Configuration¶

Navigate to /opt/gpudb/httpd/conf/noauth.conf and uncomment the following settings, ensuring you replace the SSLCertificateFile and SSLCertificateKeyFile setting values with the proper file paths. Read the Apache HTTPD SSL Docs for more information
```
SSLEngine On
...
SSLCertificateFile </path/to/cert>
SSLCertificateKeyFile </path/to/key>
SSLProxyEngine On
RequestHeader set X-Forwarded-Proto "https"
```

Important

The following settings are optional but provide greater security. Depending on what version of OpenSSL is installed on the system, the TLS version should be updated. The SSLCipherSuite setting can also be upgraded, e.g., SSLCipherSuite HIGH:!aNULL:!MD5:

SSLProtocol -all +TLSv1.1
SSLCipherSuite HIGH:MEDIUM
Header edit Set-Cookie ^(.*)$ $1;HttpOnly;Secure

Kinetica Components Configuration¶

Reveal¶

Navigate to /opt/gpudb/connectors/reveal/etc/default.json and update the url setting:
```
"gadmin": {
  "url": "https://localhost:8443/gadmin"
},
```

GAdmin¶

Navigate to the /opt/gpudb/tomcat/webapps/gadmin/js/settings.js file and update the PORT variable to the secured Reveal port (default is 8444):
```
var REVEAL = {
  PORT: '8444',
  ...
```
Navigate to the /opt/gpudb/tomcat/webapps/gadmin/WEB-INF/classes/gaia.properties file and update the following settings for https, ensuring the host is correct for your setup
```
gpudb_ext_url = https://<hostname>:8082/gpudb-0

...
gpudb_ext_hm_url = https://<hostname>:8082/gpudb-host-manager
```
Update the kisql_ca_cert_path setting for the filepath to the SSL certificate:
```
kisql_ca_cert_path = </file/path/to/ssl-cert>
```
Navigate to the /opt/gpudb/tomcat/conf/catalina.properties file and add the following settings to the bottom of the file, ensuring you replace the trustStore setting value with the proper file path and the trustStorePassword setting with the correct password
```
javax.net.ssl.trustStore=</path/to/keystore>
javax.net.ssl.trustStorePassword=<your-keystore-password>
```

Important

A keystore being added to catalina.properties will prevent security settings from being overwritten during a Kinetica upgrade

External Authentication Configuration¶

External authentication data store integration with Kinetica is accomplished through an Apache HTTPD proxy. This proxy comes packaged with Kinetica and can be found in /opt/gpudb/httpd. Since this portion is controlled by Apache HTTP not Kinetica, see the Apache documentation for further details. External authentication can be configured for Kinetica with or without SSL.

Kinetica currently supports the following external authentication sources:

LDAP
Microsoft Active Directory
Kerberos

Note

For testing purposes, Kinetica is packaged with an OpenLDAP server daemon (slapd) that already includes several sample users. It can be started & initialized manually, using the commands:

$ sudo /opt/gpudb/httpd/gpudb-openldap.sh start
$ /opt/gpudb/httpd/openldap/openldap-init.sh

Note

Only run /opt/gpudb/httpd/openldap/openldap-init.sh the first time the included OpenLDAP instance is started.

LDAP¶

Before making configuration changes, ensure host manager is stopped:
```
service gpudb_host_manager stop
```

Navigate to /opt/gpudb/httpd/conf/data.conf, uncomment the following settings, and update them as necessary. Read more about the HTTPD LDAP settings in the Apache HTTPD LDAP documentation:

# Clear the REMOTE_USER and KINETICA_ROLES headers, so that they
# cannot be passed through by the client.
Header unset REMOTE_USER
Header unset KINETICA_ROLES

## The following is an example configuration for authenticating Kinetica
## users against an LDAP server. Please refer to the Apache httpd
## configuration manual for assistance. Note that in order to use LDAP
## authentication, enable_external_authentication must be set to true in
## gpudb.conf.
AuthName "Kinetica Authentication"

## LDAP server URL and full LDAP path to users directory with search
## parameters. If an attribute other than "uid" is used for the user ID,
## update it below.
AuthLDAPUrl ldap://<ldap-hostname:ldap-port>/dc=gpudb,dc=com?uid?sub

## Valid LDAP user to use for search during bind
AuthLDAPBindDN cn=admin,dc=gpudb,dc=com
## Password of user for search during bind
AuthLDAPBindPassword admin

AuthType Basic
## The following (AuthBasicAllowAnonymous) is a custom httpd configuration
## parameter which will allow failed LDAP lookups to trickle through to
## GPUdb, where it can attempt an internal authentication and/or reach
## endpoints without credentials if auth is not required.  This can be
## turned off when internal users are not being used, and no anonymous
## access is desired.
AuthBasicAllowAnonymous on
AuthBasicProvider ldap
AuthzLDAPAuthoritative on

## To attempt authentication, uncomment the following
## <LimitExcept>..</LimitExcept> block.  Once authentication is enabled,
## you can also limit access to gpudb and translate LDAP groups to
## Kinetica Roles...
##
## To prevent users outside certain LDAP groups from accessing the
## system, uncomment the <RequireAny> block within the <LimitExcept>
## block below, and list each accepted LDAP group, one per
## Require ldap-group entry, in the format:
##
##     <RequireAny>
##         Require ldap-group <ldap-group1-cn>
##         ...
##         Require ldap-group <ldap-groupN-cn>
##     </RequireAny>
##
## If membership in all groups is required, rather than any one of the
## groups, change the RequireAny tags to RequireAll tags.
##
## To translate membership in LDAP groups to membership in Kinetica
## roles, uncomment the <RequireAll> block within the <LimitExcept>
## block below, and replace the example mappings with mappings in the
## format:
##
##     <RequireAll>
##         Require kinetica-ldap-role-mapping <kinetica-role1-to-grant> <ldap-group1-cn>
##         ...
##         Require kinetica-ldap-role-mapping <kinetica-roleN-to-grant> <ldap-groupN-cn>
##     </RequireAll>
##
## Note that access is not restricted to users in these groups (use
## Require ldap-group, demonstrated above, to enforce group
## restrictions). Also note that enable_authorization,
## auto_grant_external_roles and potentially auto_revoke_external_roles
## must be set to true in gpudb.conf to enable role mappings.

<LimitExcept OPTIONS>
    <RequireAll>
        #<RequireAny>
        #    Require ldap-group cn=group1,dc=gpudb,dc=com
        #    Require ldap-group cn=group2,dc=gpudb,dc=com
        #</RequireAny>
        <RequireAny>
            #<RequireAll>
            #    Require kinetica-ldap-role-mapping kinetica-role-1 cn=group1,dc=gpudb,dc=com
            #    Require kinetica-ldap-role-mapping kinetica-role-2 cn=group2,dc=gpudb,dc=com
            #</RequireAll>
            Require valid-user
        </RequireAny>
    </RequireAll>
</LimitExcept>

...

## Add REMOTE_USER and KINETICA_ROLES HTTP headers, and do not pass
## through any AUTHORIZATION header containing LDAP credentials. Update
## the first line below if an attribute other than "uid" is used for the
## user ID.
RequestHeader set REMOTE_USER %{AUTHENTICATE_samacccountname}e env=AUTHENTICATE_samaccountname
RequestHeader set KINETICA_ROLES %{KINETICA_ROLES}e env=KINETICA_ROLES
RequestHeader unset AUTHORIZATION env=REMOTE_USER

Important

If you have groups you want to map to Kinetica roles, edit the LimitExcept tag, noted above.

Important

If using Apache HTTPD version 2.2, the LimitExcept configuration can be simplified to this:

<LimitExcept OPTIONS>
    Require valid-user
</LimitExcept>

The LDAP group mapping should also follow HTTPD 2.2 styling, as follows:

## To map LDAP groups to Kinetica roles, add the mappings here. Note
## that access is not restricted to users in these groups (use Require
## ldap-group to enforce group restrictions). Also note that
## auto_grant_external_roles must be set to true in gpudb.conf to
## enable role mappings.
Require kinetica-ldap-role-mapping role1 cn=group1,dc=gpudb,dc=com
Require kinetica-ldap-role-mapping role2 cn=group2,dc=gpudb,dc=com

Microsoft Active Directory¶

Before making configuration changes, ensure host manager is stopped:
```
service gpudb_host_manager stop
```

Navigate to /opt/gpudb/httpd/conf/data.conf, uncomment the following settings, and update them as necessary, ensuring you replace any instances of uid with samaccountname:

# Clear the REMOTE_USER and KINETICA_ROLES headers, so that they
# cannot be passed through by the client.
Header unset REMOTE_USER
Header unset KINETICA_ROLES

## The following is an example configuration for authenticating Kinetica
## users against an LDAP server. Please refer to the Apache httpd
## configuration manual for assistance. Note that in order to use LDAP
## authentication, enable_external_authentication must be set to true in
## gpudb.conf.
AuthName "Kinetica Authentication"

## LDAP server URL and full LDAP path to users directory with search
## parameters. If an attribute other than "uid" is used for the user ID,
## update it below.
AuthLDAPUrl ldap://127.0.0.1:9009/dc=gpudb,dc=com?samaccountname?sub

## Valid LDAP user to use for search during bind
AuthLDAPBindDN cn=admin,dc=gpudb,dc=com
## Password of user for search during bind
AuthLDAPBindPassword admin

AuthType Basic
## The following (AuthBasicAllowAnonymous) is a custom httpd configuration
## parameter which will allow failed LDAP lookups to trickle through to
## GPUdb, where it can attempt an internal authentication and/or reach
## endpoints without credentials if auth is not required.  This can be
## turned off when internal users are not being used, and no anonymous
## access is desired.
AuthBasicAllowAnonymous on
AuthBasicProvider ldap
AuthzLDAPAuthoritative on

## To attempt authentication, uncomment the following
## <LimitExcept>..</LimitExcept> block.  Once authentication is enabled,
## you can also limit access to gpudb and translate LDAP groups to
## Kinetica Roles...
##
## To prevent users outside certain LDAP groups from accessing the
## system, uncomment the <RequireAny> block within the <LimitExcept>
## block below, and list each accepted LDAP group, one per
## Require ldap-group entry, in the format:
##
##     <RequireAny>
##         Require ldap-group <ldap-group1-cn>
##         ...
##         Require ldap-group <ldap-groupN-cn>
##     </RequireAny>
##
## If membership in all groups is required, rather than any one of the
## groups, change the RequireAny tags to RequireAll tags.
##
## To translate membership in LDAP groups to membership in Kinetica
## roles, uncomment the <RequireAll> block within the <LimitExcept>
## block below, and replace the example mappings with mappings in the
## format:
##
##     <RequireAll>
##         Require kinetica-ldap-role-mapping <kinetica-role1-to-grant> <ldap-group1-cn>
##         ...
##         Require kinetica-ldap-role-mapping <kinetica-roleN-to-grant> <ldap-groupN-cn>
##     </RequireAll>
##
## Note that access is not restricted to users in these groups (use
## Require ldap-group, demonstrated above, to enforce group
## restrictions). Also note that enable_authorization,
## auto_grant_external_roles and potentially auto_revoke_external_roles
## must be set to true in gpudb.conf to enable role mappings.

<LimitExcept OPTIONS>
    <RequireAll>
        #<RequireAny>
        #    Require ldap-group cn=group1,dc=gpudb,dc=com
        #    Require ldap-group cn=group2,dc=gpudb,dc=com
        #</RequireAny>
        <RequireAny>
            #<RequireAll>
            #    Require kinetica-ldap-role-mapping kinetica-role-1 cn=group1,dc=gpudb,dc=com
            #    Require kinetica-ldap-role-mapping kinetica-role-2 cn=group2,dc=gpudb,dc=com
            #</RequireAll>
            Require valid-user
        </RequireAny>
    </RequireAll>
</LimitExcept>

...

## Add REMOTE_USER and KINETICA_ROLES HTTP headers, and do not pass
## through any AUTHORIZATION header containing LDAP credentials. Update
## the first line below if an attribute other than "uid" is used for the
## user ID.
RequestHeader set REMOTE_USER %{AUTHENTICATE_samacccountname}e env=AUTHENTICATE_samaccountname
RequestHeader set KINETICA_ROLES %{KINETICA_ROLES}e env=KINETICA_ROLES
RequestHeader unset AUTHORIZATION env=REMOTE_USER

Important

If you have groups you want to map to Kinetica roles, edit the LimitExcept tag, noted above.

Important

If using Apache HTTPD version 2.2, the LimitExcept configuration can be simplified to this:

<LimitExcept OPTIONS>
    Require valid-user
</LimitExcept>

The LDAP group mapping should also follow HTTPD 2.2 styling, as follows:

## To map LDAP groups to Kinetica roles, add the mappings here. Note
## that access is not restricted to users in these groups (use Require
## ldap-group to enforce group restrictions). Also note that
## auto_grant_external_roles must be set to true in gpudb.conf to
## enable role mappings.
Require kinetica-ldap-role-mapping role1 cn=group1,dc=gpudb,dc=com
Require kinetica-ldap-role-mapping role2 cn=group2,dc=gpudb,dc=com

Kerberos¶

Before making configuration changes, ensure host manager is stopped:
```
service gpudb_host_manager stop
```

Navigate to /opt/gpudb/httpd/conf/data.conf, uncomment the following settings, and update them as necessary:

# Clear the REMOTE_USER and KINETICA_ROLES headers, so that they
# cannot be passed through by the client.
Header unset REMOTE_USER
Header unset KINETICA_ROLES

## The following is an example configuration for authenticating Kinetica
## users against an LDAP server. Please refer to the Apache httpd
## configuration manual for assistance. Note that in order to use LDAP
## authentication, enable_external_authentication must be set to true in
## gpudb.conf.
AuthName "Kinetica Authentication"

Add the following settings below the settings you just uncommented, ensuring you replace the Kerberos realm and service name as well as the path to the keytab file with the appropriate values:

Allow from ALL
AuthType Kerberos
KrbAuthRealms <kerberos-realm-name>
KrbServiceName <kerberos-service-name>
Krb5Keytab </path/to/file.keytab>
KrbMethodNegotiate On
KrbMethodK5Passwd On
KrbVerifyKDC Off
KrbLocalUserMapping On
Require valid-user
RequestHeader set REMOTE_USER %{REMOTE_USER}s
RequestHeader unset AUTHORIZATION env=REMOTE_USER

Navigate to /opt/gpudb/httpd/conf/httpd.conf and add the following line to the end of the file:
```
LoadModule auth_kerb_module /opt/gpudb/httpd/modules/mod_auth_kerb.so
```

User Management¶

Once Kinetica is connected to an external authentication source, the external users can be used for all Kinetica administration. First, a user with administrative permissions that can be tied to an external user will need to be created within Kinetica:

Log into Kinetica Administration Application (GAdmin) with an internal Kinetica administration account
From the Security menu, select Users
Click the New button
For Authentication, select External
Enter an external user's username, preceded by @. This marks the user as an externally authenticated user
For System Level Permission, select System Admin

Note

Although external users are created with the username @<username>, they will log in with their regular username, without the @.

Verification¶

Restart host manager and the database using:

service gpudb_host_manager start
service gpudb start

Run a Host Manager status check:
```
service gpudb_host_manager status
```

Verify the output shows HTTPD is running:

...
Httpd            : Running (14250 14277 14278 14279 14280 14282)
...

Ensure Kinetica is running properly:

curl -k https://<hostname>:8082/gpudb-0

Verify the output shows Kinetica is running:
```
Kinetica is running!
```
Verify both internal and external users can login to GAdmin at https://<hostname>:8443
Verify both internal and external users can login to Reveal at https://<hostname>:8444

Table Of Contents

Security Configuration¶

Prerequisites¶

Authentication/Authorization Scenarios¶

HTTPD¶

Database Configuration¶

ODBC Configuration¶

Verification¶

HTTPD + SSL¶

General Configuration¶

Database Configuration¶

ODBC Configuration¶

HTTPD "Data" Configuration¶

HTTPD "NoAuth" Configuration¶

Kinetica Components Configuration¶

Reveal¶

GAdmin¶

Verification¶

HTTPD + External Authentication¶

Database Configuration¶

ODBC Configuration¶

External Authentication Configuration¶

LDAP¶

Microsoft Active Directory¶

Kerberos¶

User Management¶

Verification¶

HTTPD + SSL + External Authentication¶

Database Configuration¶

ODBC Configuration¶

HTTPD "Data" Configuration¶

HTTPD "NoAuth" Configuration¶

Kinetica Components Configuration¶

Reveal¶

GAdmin¶

External Authentication Configuration¶

LDAP¶

Microsoft Active Directory¶

Kerberos¶

User Management¶

Verification¶