There are many factors to weight when choosing which relational database management system (RDBMS) to deploy for a given application.  One reason I have been working with PostgreSQL for Keystone is that it support Kerberos Authentication.

Why Kerberize Postgresql

Direct access to the RDBMS might be required for many reasons.

• A shared instance between servers
• The database might be in a large replicated cluster managed as a service for the enterprise
• The database instance  might provide a read only snapshot of live data for reporting
• Some applications might use the Database as a persistant RPC mechanism

In the case of OpenStack, we want to make Keystone highly available.  As such, each Keystone instance will not get its own database instance, but instead will share a back end.

Puppetized Install and Configuraton

From a shell prompt:

Yum install puppet puppet-server tar postgresql
puppet module install puppetlabs/postgresql

Create a site.pp file for applying gss api to the pg_hba.conf file:

class { 'postgresql::server':
  config_hash => {
    'ip_mask_deny_postgres_user' => '0.0.0.0/32',
    #do not explicitly set 'ip_mask_allow_all_users' 
    #and it will default to localhost only
    'listen_addresses'           => '*',
    'manage_redhat_firewall'     => true,
  },
}
postgresql::pg_hba_rule { 'allow application network to access app database':
  description => "Open up postgresql for access from 192.168.0/24",
  type => 'host',
  database => 'all',
  user => 'all',
  address => '192.168.0.0/24',
  auth_method => 'gss'
}

Apply it with

 puppet apply --verbose /root/site.pp

Check the postgres access controls in /var/lib/pgsql/data/pg_hba.conf
You need a line like this.

host    all     all     192.168.0.0/24  gss

Make sure you don’t have some other rule that will conflict with it. For example, In an earlier pass I had to comment out:

#host   all     all     0.0.0.0/0       md5
#host   all     all     ::1/128 md5

Which preceded it and were triggering a password request from the psql command.

Kerberos for Postgres: Create new service in IPA.

ipa service-add postgres/pg.openstack.freeipa.org
ipa-getkeytab -s ipa.openstack.freeipa.org -p postgres/pg.openstack.freeipa.org@OPENSTACK.FREEIPA.ORG  -k /var/lib/pgsql/data/pg.keytab
chown postgres:postgres /var/lib/pgsql/data/pg.keytab

Postgres Config

Edit Postgresql.conf

The information to do this is out of the Postgres manual

# Kerberos and GSSAPI
krb_server_keyfile = '/var/lib/pgsql/data/pg.keytab'
krb_srvname = 'postgres'
host    all     all     192.168.0.0/24  krb5

Firewall:

Either iptables open port 5432:

lokkit -p 5432:tcp

Or open it with firewall-cmd:

firewall-cmd --add-port=5432/tcp

To Test:

psql -h pg.openstack.freeipa.org -d keystone -U keystone

Run klist afterwards to see the Postgres service ticket:

Ticket cache: FILE:/tmp/krb5cc_1615800001
Default principal: keystone@OPENSTACK.FREEIPA.ORG

Valid starting     Expires            Service principal
05/02/13 03:31:28  05/03/13 03:31:28  krbtgt/OPENSTACK.FREEIPA.ORG@OPENSTACK.FREEIPA.ORG
05/02/13 03:31:33  05/03/13 03:31:28  postgres/pg.openstack.freeipa.org@OPENSTACK.FREEIPA.ORG

On the Keystone side install Postgres client libraries for Keystone

yum install python-psycopg2 postgresql

In /etc/keystone/keystone.conf

connection = postgresql://pg.openstack.freeipa.org/keystone?krbsrvname=postgres

Assuming you are going to run this for a non-interactive service, you will need a cron job to fetch the tgt on a regular basis.

crontab /etc/keystone/keystone.crontab
1 0,6,12,18 * * *   su - keystone -c "KRB5CCNAME=FILE:/tmp/krb5cc_1615800001 kinit keystone -k -t /var/kerberos/krb5/user/1615800001/client.keytab"