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.
Category Archives: Software
Securing OpenStack with FreeIPA
I gave a talk at the OpenStack summit in Portland about using FreeIPA to secure OpenStack. You can see the video here. I have HTMLified my slides if you wish to browse through them.
Troubleshooting a FreeIPA install:
I had a handful of machines enrolled in a demo cluster. About half of them got shut down, and now I can’t SSH into them via Kerberos tickets. Here is my debugging notebook.
Running PostgreSQL and Mysql Unit tests in Keystone
We don’t include the postgres or Mysql drivers inside the virtual env for Keystone, so you need to explicitly install them in order to run the unit tests.
firewall-d for FreeIPA
First hack at a script to open the ports needed by FreeIPA. On Fedora 18, running Firewall D, I ran the below script. Comments and corrections welcome.
IPTables rules for FreeIPA
I end up editing this so much, figure I’d post it here for all to use. This is the standard IPtables config file augmented with those rules required to let through the protocols supported by FreeIPA
# Firewall configuration written by system-config-firewall # Manual customization of this file is not recommended. *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT -A INPUT -p icmp -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT #TCP ports for FreeIPA -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 389 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 636 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 88 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 464 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT #UDP ports for FreeIPA -A INPUT -m state --state NEW -m udp -p udp --dport 88 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 464 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 123 -j ACCEPT -A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT -A INPUT -j REJECT --reject-with icmp-host-prohibited -A FORWARD -j REJECT --reject-with icmp-host-prohibited COMMIT
Trusts and OAuth
We had a recent IRC discussion about the design of Trusts and how it compares with OAuth version 1.
Continue reading
Trusts and Role Based Access Control for Open Stack
Bearer tokens are vulnerable to replay attacks. OK, so what are our options? Something where the user proves, via cryptography that they have the right to actually use the token. It doesn’t matter if it is X509, Kerberos, or something we cook up ourselves, it is going to resolve to proving you have the right to use that token.
If tokens must be validated by the owner, we effectively break the ability of Open Stack to hand around bearer tokens to get work done. We are going to have to get a lot of stuff right in order to keep from breaking things. Fortunately, we now have the tools to work around this, and to better secure an OpenStack system: Trusts and Role Based Access Control.
Continue reading
Keystone, MySQL and Fedora 18
It looks like the access model for MySQL has changed between F17 and F18.
openstack-db fails with a permission on the root user. However, the following works:
- As the keystone user (I suspect the openstack-db call made the keystone user, or maybe that is done by the RPM install?)
- run mysql, (no params, using the default identification, which I assume is PAM based?)
- create a user named keystone.
- and grant that user perms to create a db.
su - keystone mysql
create user 'keystone'@'localhost' identified by 'keystone'; grant all PRIVILEGES on *.* to 'keystone'@'localhost';
exit mysql and log in as that user:
mysql --user=keystone --password=keystone
Create the keystone database:
create database keystone;
Log out and run the dbsync
keystone-manage db_sync
Obviously, this leaves the DB User with too many permissions, but it is a start.
If I now try to run the command
openstack-db --service glance --init Please enter the password for the 'root' MySQL user:
Even setting the password in MySQL doesn’t work
UPDATE mysql.user SET Password=PASSWORD('keystone') WHERE User='root' AND Host='localhost';
[root@f18-keystone mysql]# openstack-db --service glance --init Please enter the password for the 'root' MySQL user: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) Failed to connect to the MySQL server. Please check your root user credentials.
I tried it with the unix password as well.
Note that I can connect using the following SQL Alchemy URL:
connection = mysql://keystone:keystone@localhost/keystone?unix_socket=/var/lib/mysql/mysql.sock
I think this is preferable to exposing TCP sockets around in the case that the Keystone server and MySQL server are co-located.
Meet the Red Hat OpenStack Team: Adam Young
We thought it would be a good idea to have a “Meet the Red Hat Open Stack Team” series of blog post. This is me.
Continue reading