Ansible modules for oVirt

I did short video introduction to oVirt Ansible modules, feel free to check it out.

Deploying ManageIQ to oVirt with Ansible

In this blog post I will show you how to deploy ManageIQ appliance to oVirt engine using Ansible.
Prerequisites:
- Ansible 2.2 - Ansible modules for oVirt are available since Ansible 2.2.
- oVirt 4.0.4 - ImageIO is avaible since 4.0.4 (used to upload qcow disk).
The playbook here created will assume that you will run the playbook from the oVirt engine machine. So first please ssh to your oVirt machine. Now install the role which will handle the deploying the ManageIQ, it's called machacekondra.ovirt-manageiq and in order to install it run following command:
Now please ensure that oVirt imageio is properly setup and running. As noted here you should check the ovirt-imageio-proxy service is running on your oVirt engine and ovirt-imageio-daemon service on your hosts. The other important thing is to use proper CA of your oVirt engine, the path can be specified using ovirt_ca variable in your playbook, which is by default /etc/pki/ovirt-engine/ca.pem.
That's it, if you did all steps before correctly, you can now create the playbook:
Please change the URL of you oVirt engine and the password of your user, you can also change other variables as needed, you can find the explanation of variables here. I am strongly suggesting using Ansible vault for your passwords. Now save your playbook to some yaml file, for example manageiq.yml.
Now run the playbook:
Wait until the playbook exit, then check your oVirt engine VMs, you should find there manageiq VM running.
Note, that there is now new better role under oVirt organization on galaxy.

Client certificate authentication with oVirt

This post will show you how to configure authentication using client certificates. FreeIPA 4.2.0 introduced support for multiple certificate profiles, including support for user certificates. So we will use integration with FreeIPA 4.2. Please follow this post to create new profile for issuing user certificates in FreeIPA.

Test user creation

We create our user testing user in IPA, please be carefull specifying email address and login, we will need these later on.

pkcs#12 creation

First, we need to create private key for our user: Second, we have to create certificate signing request(CSR), using config, where we specify subjectAltName extension, which must match our user's email address in FreeIPA and commonName which must match user's login. We can now submit our CSR to IPA to issue certificate for our user. Remember to specify our user's login and profile for user certificates. Now, we need to extract user's cetificate. Now lets finnaly create our pkcs#12. Which you can later use with your browser to login.

Apache mod_ssl configuration

Now ssh to your oVirt machine. We need to reconfigure apache mod_ssl module, to require client certificate and since oVirt's AAA works with X-Remote-User header, we need to set it to REMOTE_USER env variable. Please add following lines into /etc/httpd/conf.d/ssl.conf. Now add CA certificate of ipa to /etc/pki/ovirt-engine/apache-ca.pem

oVirt AAA configuration

Authz configuration: Authn configuration: example.properties - specify your specifc creadentials and values for your IPA server Restart ovirt-engine and httpd

Let's try login

Please assign your user some permissions, in our case we assign user omachace SuperUser permission on system. Then we are able login as follows: In order to try it with our browser, please find relevant documentation how to import your pkcs#12 into browser, then you will be able to connect to oVirt via browser using client certificate.

CN to username mapping

In some setups you can met with situation, that your CN and username don't equal, in that moment you can use mapping extension. Imagine situation that in your CN is 'Ondra.Machacek' instead of 'omachace'. Then you would create a new mapping properties file as follows: And then don't forget to link this mapping to authn extension.

ovirt-engine-extension-aaa-jdbc introduction & settings customization

oVirt 3.6 introduced new extension called  ovirt-engine-extension-aaa-jdbc. If you upgrade from older version or if you install fresh new 3.6 you will have this extension installed and configured. With this extension you can store you users/group in database. Very good for people who don't need much users and don't want to deploy LDAP. Note that your admin@internal will now be part of this extension, this migration is done transparently by engine-setup.

Auth[zn] files for internal extension can be found in etc/ovirt-engine/extensions.d/internal-authz.properties and etc/ovirt-engine/extensions.d/internal-authn.properties. Nothing interesting can be found those two files. In common configuration of auth[zn] you can then find database connection settings, which you will find in etc/ovirt-engine/aaa/internal.properties. Content of the file looks like: As you can see only there are db connection details specified, so very easy configuration. Please note there is specified name of postgresql schema, which is in this case aaa_jdbc.

Exploring tables

Wanna check the data aaa-jdbc extension store? You can do as follows:
As you can see your admin account is now part of this extension as said above.
Well, this is not too comfortable to work with your users. The extension provide CLI tool to manage the users more comfortable way.

CLI tool 

Cli too name is ovirt-aaa-jdbc-tool. Not much I can say about this tool, since it has good documentation in help.
So whenever you are in doubt what to use just append --help to your args. Please note that by default use the command user @internal extension. If you want to use different one just pass --db-config=/path/to/db/settings.properties of your configuration.

Adding user via CLI tool

If you explored help of this tool you can see there is user module, which you can use to manage users. So we will add  some users, which we will use later in this blog post. Please note that by default freshly added users don't have set password, so you need to set it.

Changing settings via CLI tool

As there is user module there is also settings module to change settings of aaa-jdbc extension. To see what you can change simply run 'ovirt-aaa-jdbc-tool settings show'. There are lot of stuff you can change, the most important/interesting I will show you later.

Policies

Password history limit

You can use setting option PASSWORD_HISTORY_LIMIT  to prohibit user to set same password as he used before. Limit can be integer value, by default it's 3. That means user can't change password to last three passwords he used before.

To change it, use command below(set it to 5):

Password complexity 

Minimal lenght
To set minimal lenght of password you have to change MIN_LENGTH option. By default it's 6. Password complexity
To set complexity of password you have to change PASSWORD_COMPLEXITY option. You can create different complexity groups. By default there is no restriction.  So if you want to for example your user force to have at least one upper case letter, lower case letter and number in his password run the command below:

Account & login policy

 

Non locking policy after failed login
To prevent brute force attacks to your account and at the same time prevent denial of your account you can set non locking policy when there is too many attempts to guess password to your user account. To set it use MAX_FAILURES_PER_MINUTE option. By default it's set to 6.

Locking of account after failed login
You account can be locked after X failed logins. There are two options to configure that.
First possibility is to set  MAX_FAILURES_SINCE_SUCCESS this option means that user account is locked after X unsuccessfull login attempts to your account after last successfull login.

The second possibility is to set MAX_FAILURES_PER_INTERVAL this options means that your user account will be locked after X unsuccesfull login attempts to your account in X hours. The value of hours can be set  in option INTERVAL_HOURS.

Your accounts are locked to X minutes. The amount of minutes can be changed by value of option LOCK_MINUTES. Or you can unlock your user by running cli command:
$ ovirt-aaa-jdbc-tool user unlock user1

Removing of failed login
Failed login can be automatically removed during house keeping. All failed login which are older then X days specified in option FAILED_LOGINS_OLD_DAYS will be removed.

Other

 

Max login minutes

With MAX_LOGIN_MINUTES option you can set how long your user can be logged in. If time exceeds, he will be automatically logged out.

Many others

There are many other options. You can explore them by yourself, just run:
$ ovirt-aaa-jdbc-tool settings show

SAML and oVirt 3.5

Same way as kerberos is supported for oVirt 3.5 there is also support for SAML via apache module.

There are few SAML apache modules, but I chose mod_auth_mellon, as it has very nice documentation.

First of all we need to setup some identity provider. I chose OpenAM. Please follow steps to quick install of OpenAM with embedded OpenDJ ldap.

OK I presume, that you have up and running OpenAM on tomcat with embedded OpenDJ ldap.
Next step is to setup ourt OpenAM as Identity Provider. Go to 'common-tasks' tab and hit the button 'Created Hosted Identity Provider'. Set name  of your metadata(your URL). Signing key, if you want. Then create new CoT and named it as you like, not important for us. Now very important thing. You need to add attribute mapping, so we are able to map the uid of user in ldap to REMOTE_USER env of apache. Please set 'Name in assertion' to 'common-name' and 'Local attribute name' to 'cn'. And we are done.

Apache configuration

Now we need to setup oVirt apache as service provider(I am using RHEL 6.6):

• Install mod_auth_mellon apache module:

• Obtain IdP metadata:

• Create SP metadata:

• Previous step will create for you three files:

             WHAT_EVER_SP_ENTITY_NAME_ID.xml
             WHAT_EVER_SP_ENTITY_NAME_ID.key
             WHAT_EVER_SP_ENTITY_NAME_ID.cert 

• copy them to the /etc/httpd/mellon  and asure that all files and folder can be read by apache.

• Create mod_auth_mellon configuration:

• In OpenAM go to 'common-tasks' , hit 'register remote service provider'. Upload your SP metadata WHAT_EVER_SP_ENTITY_NAME_ID.xml. Choose already cretead CoT. That's all, click 'configure'.

oVirt AAA configuration

We had setup both mod_auth_mellon as SP and OpenAM as IdP. Last thing is to setup oVirt to respect this setup.

• Install oVirt AAA packages:
• Authn configuration:
• Authz configuration:
• Connection configuration:
• This is custom properties file of opendj, I've created it for this example saml configuration. It's not supported by oVirt:
• Check correct persmissions of all properties file, it have to be readeble by oVirt.

No we will create test user in OpenDJ. Go to OpenAM -> 'Access Control' tab -> select your realm (default /). Click 'Subjects' tab -> Add new user -> Fill appropriate values. (ie user1.)

Now go to oVirt webadmin and search within 'http' profile for user1 and assign him permissions. Now go to ovirt-engine/api URL and you will be forwarded to OpenAM login screen, fill your credentials and you are now able to access rest-api.

Tool which will help you migrate from legacy kerbldap to new AAA

Since oVirt 4.0 there will be no support for legacy kerbldap domains (added via engine-manage-domains command). A tool that will help your to migrate to new AAA was written. Please refer to README to more information.

openldap stops work with ovirt when uprage into fedora 20

I have recently upgraded openldap to fedora 20 and I had
openldap connected into ovirt 3.5. Everything went
smooth but openldap didn't work with ovirt. The first issue,
is common for all almost all ldap providers since it was cyrus-sasl-lib
bug. There was an easy workaround with setting sasl_qop into auth.

But there was another issue which I don't why happend, but ovirt
send kerberos request:
ldap/localhost@REALM
instead of
ldap/fqdn@REALM,

So to easily workaround this problem just add:

$ kadmin.local:
add_principal -randkey ldap/localhost@REALM
ktadd -keytab your_keytab_path ldap/localhost@REALM

Then restart openldap, and everything goes fine now. :)