What Policy is enforced when you call a Keystone API? Right now, there is no definitive way to say. However, with some programmatic help, we might be able to figure it out from the source code. Lets start by getting a complete list of the Keystone routes.
While trying to debug an Ansible module calling Certmonger, I found myself afoul of some mistake I could not quite trace. Certmonger was having trouble reading the key to generate the certificate. But nothing was showing up in the log. Here’s how I got some logging info.
Operators expect to use CloudForms to perform administrative tasks. For this reason, the documentation for OpenStack states that the Keystone user must have an ‘admin’ role. We found at least one case, however, where this was not sufficient. Fortunately, we have a better approach, and one that can lead to success in a wider array of deployments.
I’ve been working on setting up a Java based SAML provider. This means that the application needs to handle request and response over HTTPS. And, since often this is deployed in data centers where non-standard ports are blocked, it means that the HTTPS really needs to be supported on the proper port, which is 443. Here are the range of options.
Now that I know that I can do things like read the Keys from a Programmatic registered provider and properly set up SELinux to deal with it, I want to see if I can make this work for a pre-compiled application, using only environment variables.
Earlier this week, I got some advice from John Dennis on how to set up the certificates for a Java based web application. The certificates were to be issued by the Dogtag instance in a Red Hat Identity Mangement (RH IdM) install. However, unlike the previous examples I’ve seen, this one did some transforms from the certificate files, into PKCS12 and then finally into the keystore. It Looks like this:
ipa-getcert request -f /etc/pki/tls/certs/rhsso-cert.pem -k /etc/pki/tls/private/rhsso-key.pem -I rhsso -K RHSSO/`hostname` -D `hostname` openssl pkcs12 -export -name rhsso -passout pass:FreeIPA4All -in /etc/pki/tls/certs/rhsso-cert.pem -inkey /etc/pki/tls/private/rhsso-key.pem -out rhsso.p12 keytool -importkeystore -srckeystore rhsso.p12 -srcstoretype PKCS12 -srcstorepass FreeIPA4All -destkeystore keycloak.jks -deststorepass FreeIPA4All -alias rhsso keytool -keystore keycloak.jks -import -file /etc/ipa/ca.crt -alias ipa-ca cp keycloak.jks /etc/opt/rh/rh-sso7/keycloak/standalone/
Aside from the complications of this process, it also means that the application will not be updated when Certmonger automatically renews the certificate, leading to potential down time. I wonder if there is a better option.
So I uploaded a qcow image…but did it wrong. It was tagged as raw instead of qcow, and now I want it gone. Only problem….it is stuck.
If you are using RDO Cloud and want to do command line Ops, here is the outline of a keystone.rc file you can use to get started.
Nothing lasts forever. Except some developer setups that no-one seems to know who owns, and no one is willing to tear down. I’ve tried to build the code to clean up after myself into my provisioning systems. One pattern I’ve noticed is that the same data is required for building and for cleaning up a cluster. When I built Ossipee, each task had both a create and a teardown stage. I want the same from Ansible. Here is how I’ve made it work thus far.