Keystone supports multiple backend for Identity. While SQL is the default, LDAP is one of the most used. With Federation protocols, the user data won’t even be stored in the identity backend at all. All three of these approaches have different use cases, and all work together. The way that that I’ve come to think of them is as three types of Keystone users: employees, partners, and customers. Take the following as a metaphor, not literal truth.
Phishing
Kerberos was slow when talking to my demo machine. As part of debugging it, I was making DNS changes, so I pointed my machine directly to the DNS server. It was at my hosting provider, and authoritative for my domain.
As I tend to do, I idly checked Facebook. Its a bad habit, like biting nails. Sometimes I’m not even aware that I am doing it. This time, however, a browser warning brought me up short:
The certificate reported that it was valid for a domain that ended in the same domain name as the nameserver I was pointing at.
Someone just like me had the ability to push up whatever they wanted to the DNS server. This is usually fine: only the Authoritative DNS server for a site is allowed to replicate changes. It did mean, however, that anyone that was looking at this particular DNS server would be directed to something they were hosting themselves. I’m guessing it was a Phishing attempt as I did not actually go to their site to check.
Most of us run laptops set up to DNS from the DHCP server we connect to. Which means that if we are at a Coffee Shop, the local library, or the Gym, we are running against an unknown DNS server. The less trusted the location, the less reason to trust the DHCP server.
This is a nasty problem to work around. There are things you can do to mitigate, such as whitelisting DNS servers. The onus, however, should not be up to the end users. DNSSec attempts to address the issues. Until we have that, however, use HTTPS where ever possible. And check the certificates.
Getting Service Users out of LDAP
Most people cannot write to the LDAP servers except to manage their own data. Thus, OpenStack requiring the Service users in LDAP is a burden that many IT organizations cannot assume. In Juno we have support for Multiple backends for domains.
Continue reading
Devstack mounted via NFS
Devstack allows the developer to work with the master branches for upstream OpenStack development. But Devstack performs many operations (such as replacing pip) that might be viewed as corrupting a machine, and should not be done on your development workstation. I’m currently developing with Devstack on a Virtual Machine running on my system. Here is my setup:
Oh No! I Committed to master! What do I do?
You were working in a git repo and you committed your change to master. Happens all the time. Panic not.
Continue reading
Kerberos for Horizon and Keystone
I have a Horizon instance Proof of Concept. It has a way to go to be used in production, but the mechanism works.
Continue reading
Audit Belongs with Policy
Policy in OpenStack is the mechanism by which Role-Based-Access-Control is implemented. Policy is distributed in rules files which are processed at the time of a user request. Audit has come to mean the automated emission and collection of events used for security review. The two processes are related and need a common set of mechanisms to build a secure and compliant system.
Continue reading
Why POpen for OpenSSL calls
Many people have questioned why I chose to use popen to call the OpenSSL binary from Keystone and the auth_token middleware. Here is my rationale:
Continue reading
Unattended Install of a FreeIPA Server
As a developer, I install and uninstall the application I’m working on all the time. Back when I was working on FreeIPA full time, I had a couple of functions that I used to do an unattended install with some simple defaults. I recently cleaned them up a little. Since a few people have asked me for them, I’m posting them here.
Kerberos and Firewalls
Most datacenters block non-standard ports at their firewalls. This includes ports for lesser used protocols. The Kerberos Key Distribution Center (KDC) listens on port 88 (TCP and UDP). Which means that, practically speaking, a machine cannot get a ticket over the public internet. Last summer, Robby Harwood interned here at Red Hat. Together, we put together a plan to address this.
Continue reading