Category: Integration

Using Keycloak as the IdentifyProvider (to Login) to Hashicorp Vault

I like Keycloak a lot.
A single place to manage your authentication for many systems that you can use to federate users from an existing directory of users.

For more information look at my Keycloak Essentials fixes blog

There are a host of benefits but mainly it lets applications focus on their goals and not be distracted by the complex task of authentication.

If you are making use of keycloak and vault in your environment, then I would say it is worth looking at providing auth into vault via keycloak. Even if your users are in directory that can be accessed with LDAP - federating those users with keycloak and using OpenIDC auth is better than directly using LDAP - as credentials will be entered into only a single place ever.

Before jumping in, it is worthwhile taking a look at Vault1.1: OpenIDC with vault youtube tutorial

Key terminology:

  • Claims: key/value pairs in the JWT id token - a OpenIDC JWT term
  • Client Scopes: A keycloak term, tedious to configure protocol and role scope mappings for each client. These are shared scope mappers. By default the SAML client uses the roles_list and openidc has profile, email, address, phone, offline_access, roles, web-origins and microprofile-jwt

Prerequisites

Ensure you have setup the following:

  • keycloak (I used version 9.x)
  • Vault 1.1 or higher (I used Vault v1.3.4)

Getting Started

Keycloak Client Setup

Hashicorp provides decent docs and have a section on setting up your OIDC provider. We will use that to set up the hashicorp client in your keycloak realm.

  1. Log into keycloak and use the correct realm
  2. Create a client
    • Client Protocol: openid-connect
    • Access Type: confidential
    • Standard Flow Enabled: On
    • Configure Valid Redirect URIs
  3. Make note of the Client ID and Secret

Also ensure that valid redirect URL's are used:

valid-redirect-urls-vault

https://<vault_server_address>:8200/ui/vault/auth/oidc/oidc/callback,
https://<vault_server_address>:8250/oidc/callback

Vault Info

Vault provides information about the JWT/Open ID Connect auth method.

A JWT (said jot) is a JSON web token - this is a token containing authentication information that is signed by the identify provider - made available to the client.
That is how the client knows the identity of the user.

Vault allows login using the authorization code flow (via browser) with keycloak - or direct entry of the JWT.

Key Concepts

Remember that sometimes we want to maintain order and not just authorize any user on keycloak to login. In that case, Bound Claims are used.
These are the required keys and values expected to be in the JWT in order for that JWT to be authorized.

For example only user's with the attributes in the client scope of the JWT like the following:

{
        'department': 'implementations',
        'region': 'za'
}

Are allowed in.

Apparently the mapping is done on vault side with claim_mappings...and this must exist in the JWT other wise auth fails.

Note: the metadata key name "role" is reserved and may not be used for claim mappings.

Redirect URI's

Different from other integrations - vault requires setting the redirect URI. On other integrations usually you just set the OpenIDC endpoint...but in vault's case you need to set the redirect urls correctly as well.

The allowed_redirect_uris is specified per role.

If you plan to support authnetication via vault login -method=oidc, then a localhost redirect must be set http://localhost:8250/oidc/callback.

If you are allowing logging in via the vault ui you would use https://{host:port}/ui/vault/auth/{path}/oidc/callback.

The example given is: https://vault.example.com:8200/ui/vault/auth/oidc/oidc/callback?namespace=my_ns

So I am assuming this redirect url is the one on the vault side?...we'll figure this out

Logging in Via UI

Once everything is setup the login with openidc should look like this:

login-openidc

More info in the docs...on login via CLI and troubleshooting

Vault Setup

I am following this tutorial: Tutorial for Implementing OpenIDC Access

Ensure you have all the required details on hand:

  • keycloak baseurl (or realm url)
  • client-id
  • client-secret

Create the Policies for the Demo

Every client token has policies attached to it to control its secret access

Create a secret reader and a secret manager policy:

manager.hcl:

# Manage k/v secrets
path "/secret/*" {
    capabilities = ["create", "read", "update", "delete", "list"]
}

reader.hcl:

# Read permission on the k/v secrets
path "/secret/*" {
    capabilities = ["read", "list"]
}

I'm going to do most of this stuff using the UI - but as always with vault you can use the API or the CLI as well

  1. Go to https://<yourvault-instance>:8200/ui/vault/policies/acl
  2. Click Create ACL policy
  3. Upload the files, or just paste the contents of the .hcl's above

Enable OIDC Auth Method

  1. In the Web UI, select Access
  2. Slick Enable new method
  3. Select OIDC
  4. Enable method
  5. In configuraton add the OIDC discovery URL: https://<keycloak-url>/auth/realms/<realm>
  6. Enter reader in the Default_role field
  7. Add the client-id and client-secret in the OIDC options tab
  8. Save

Now a reader role needs to be created that binds the client and sets the allowed redirect urls:

vault write auth/oidc/role/reader \
        bound_audiences="<client-id>" \
        allowed_redirect_uris="http://<vault_server_address>:8200/ui/vault/auth/oidc/oidc/callback" \
        allowed_redirect_uris="http://<vault_server_address>:8250/oidc/callback" \
        user_claim="sub" \
        policies="reader"

All the above should match the setup redirect url's in keycloak.

From a keycloak perspective the discovery URL will always be the URL of the endpoint configuration on the realm level...but with everything after and including /.well-known removed

Login with OpenIDC

Logout and then sign in with openIDC provider.
A popup will redirect to keycloak for auth, and then close when completed.

vault-login-openidc-keycloak

Creating the Role for the Manager on Keycloak

By default, users will be secret readers.

On keycloak create a new role and add a user to that group, call is kv-manager for example.

In keycloak - roles by default are added to the client scope - so clients can view the roles of a particular user with the JWT.

  1. To create a global role Roles -> add Role or a client level role got to the client and roles
  2. Add the secret_manager role
  3. Optionally set other attributes
  4. Add a user to that role

Creating the Vault Manager Group

Concept: When you login, vault will see the roles claim groups_claim="roles" in the id token coming from the keycloak default openidc client scope. It is going to iterate over the list of values it finds. If it finds any that matches a group alias eg. secret_manager it will add that user to that group - if they are not already a member. As a result, that token they use to login with have that group's policies included.

So we are using the role secret_manager on keycloak.

The manager policy has already been created.

The original role will be extended to add a groups_claim.

Then we create a vault (external) group - that is attached to the manager policy and save its id.

Then we create a group alias that is attached to that vault external group we just created - bound to the oidc authentication method that can have any named alias.

Create the External Group:

Create the secret_manager role

Looks like this has to be done via CLI

vault write auth/oidc/role/secret_manager \
        bound_audiences="<client-id>" \
        allowed_redirect_uris="http://<vault_server_address>/ui/vault/auth/oidc/oidc/callback" \
        allowed_redirect_uris="http://<vault_server_address>:8250/oidc/callback" \
        user_claim="sub" \
        policies="reader" \
        groups_claim="roles"

I think the above policy should maybe be manager, but will have to see

Create an external group named manager linked to the manager policy

vault write identity/group name="manager" type="external" \
        policies="manager" \
        metadata=responsibility="Manage K/V Secrets"

Retain the returned ID:

export GROUP_ID="17..."

Now we need to link the manager group to the secret_manager role:

# Get the mount accessor value of the oidc auth method and save it in accessor.txt file
$ vault auth list -format=json  \
        | jq -r '."oidc/".accessor' > accessor.txt

# Create a group alias named "kv-mgr"
$ vault write identity/group-alias name="secret_manager" \
        mount_accessor=$(cat accessor.txt) \
        canonical_id="$GROUP_ID"

Try Login now

Now sign out and log in again.
Set the role as secret_manager and then login with OIDC Provider.

If everything goes according to plan, you should login and have the manager policies attached.

This was not the case for me and I got the following error:

Token verification failed. error validating claims: aud claim does not match any bound audience

vault-openidc-manager-aud-claim

I think the reason for the error is because the roles claim is not found...so the id token returned from keycloak didn't have the roles key in it.

Adding Roles to the ID Token

Addng the roles to the id token is done using a client protocol mapper

Remember vault uses the id token not the access token so the access token debug won't be as useful -
You can debug the access token within keycloak by going to: Vault Client -> Client Scopes -> Evaluate then use the secret manager user.

What you have to do is ensure that the client or realm roles is setup and added to the id token - you do that by going to the client mapper -> Add built IN and selecting the client or realm roles.

After that click the mapper and ensure Add to ID token is set to True.

add-to-id-token-keycloak-client-roles

My role was on the id token but it looked like this:

  "resource_access": {
    "vault-dev": {
      "roles": [
        "secret_manager"
      ]
    },

So that is a few more levels deep than expected.
So with a nested groups claim, you can make use of a json pointer.

In this case:

"/resource_access/vault-dev/roles"
vault write auth/oidc/role/secret_manager \
        bound_audiences="<client-id>" \
        allowed_redirect_uris="http://<vault_server_address>/ui/vault/auth/oidc/oidc/callback" \
        allowed_redirect_uris="http://<vault_server_address>:8250/oidc/callback" \
        user_claim="sub" \
        policies="reader" \
        groups_claim="/resource_access/vault-dev/roles"

So I update that, and try again - if you get this error it means the role was not found on the id token:

"/resource_access/vault-dev/roles" claim not found in token

Login Success

Now login should work successfully...

So a bit of extra work figuring things out but now things are looking good. I don't really like the flow of having to specifify the role you want to log in as explicitly but I'm sure there is a reason for this.

As for the next steps, I want to figure out why you have to speciify the role to use when logging in. Why doesn't vault get your associated roles and groups and apply the merged polcies. Perhaps that is the issue - if the roles conflict.

Using Keycloak Identity Provider for Rancher SSO

In Rancher 2.1.0 they added support for SAML authentication with Keycloak. What this means is Rancher will use a Keycloak realm to authenticate users.

This means that there is one place to manage users for a host of your applications. It also means that if they have logged on to the realm with their browser they can have single sign on to rancher - ie. they will already be logged into rancher.

The documentation on Rancher setting up Keycloak auth is already pretty good, however certain things can get tricky espescially if you are using Keycloak 7 and up.

So let's jump in and set it up...

Prerequisites

  • A Keycloak Identity Provider Setup
  • A Rancher Instance

Setting up the Rancher Client on Keycloak

In keycloak you already have a realm and user's eith local or federated from LDAP.

So now we need to create the client for Rancher.

Go to Clients -> Create:

keycloak-rancher-saml-add-client

Now add the following extra settings (replace the white box with your Rancher URL):

keycloak-saml-client-for-rancher-config-1keycloak-saml-client-for-rancher-config-2Boom, we've setup the keycloak side. Now we just need to export this config to load onto the rancher side.

Usually this would be done on the Installation tab of the client. However rancher wants the SAML Metadata IDPSSODescriptor but Keycloak 7 does not provide that.

The way to get it is to go to this URL:


https://{KEYCLOAK-URL}/auth/realms/{REALM-NAME}/protocol/saml/descriptor

and save that XML to a file.

You then need to copy all the properties of EntitiesDescriptor and add them to the first EntityDescriptor.  Then delete the EntitiesDescriptor element.

Now save that and it will be the config to import.

Setting up Keycloak Auth on Rancher

Open Rancher on the Global scope and select Security -> Authentication:

rancher-global-security-authentication

You will get a few authentication / identity provider options:

rancher-2.3-authentication-options

Select Keycloak and you will need the following information.

Field Description
Display Name Field The AD attribute that contains the display name of users.
User Name Field The AD attribute that contains the user name/given name.
UID Field An AD attribute that is unique to every user.
Groups Field Make entries for managing group memberships.
Rancher API Host The URL for your Rancher Server.
Private Key / Certificate A key/certificate pair to create a secure shell between Rancher and your IdP.
IDP-metadata The metadata.xml file that you exported from your IdP server.

These AD Attributes are set on the Keycloak side at Client -> Mappers, the best thing to do is add builtin on the rancher side:

That will add the defualt attributes and it is best to add those, however for access to the groups of the user you need to map a group list attribute.

builtin-attrbutes-mapper-saml-keycloak

You would use the protocol mapper below, to map the member attribute on rancher side to a user's group list.

 

group-list-attribute-saml-keycloak

So to view the SAML attribute name just open one of the mappers and use the Friendly Name.

In my case:

Display Name Field: givenName
User Name Field: email
UID Field: email
Rancher API Host: https://yourRancherHostURL:5443
Groups Field: member

rancher-auth-keycloak-success

If successful you will be presented with this screen. If you are not successful and you have the invalid SAML attributes error, then you need to fix your attribute names.

If you only want to allow members of certain groups on the keycloak realm then you can change the options below:

rancher-keycloak-groups-authorization

So How has Our Lives Improved Since Implementing SSO

  • A central place for authentication, you don't need to manage much about auth on your application side.
  • Deletage auth and turn Time-based One Time Pin, Add terms and conditions and giving access with a simple button switch.
  • You get SSO (single sign on): sign on to the realm and now you can simply press the login button on any other linked client and you will be logged in.
  • Single sign off - I tested this and it did not work. Logging out of one client kept you in the other client.

Single Sign Out

During my testing single sign out was not working. However I must mention my setup was 3 parts:

  • Keycloak on a VM accessible only on the local network
  • A Django App in a docker container on my local machine
  • Rancher also accessible on the local network

So my guess is that when using the front channel (browser) for the authentication step on the django client, it works because the redirect from the client goes to the docker container.

However when the logout is sent on the backchannel, it can't access 0.0.0.0:8000 as there isn't a proper DNS entry.

What I am going to do is deploy the docker container on Openshift (god bless my soul)...and set an ip or dns so that keycloak can access it on the back channel.

 

 

Sources

continuous integration: Jenkins Automated Deployments with a Private git server

What is Jenkins?

A continuous integration tool written in Java. Continuous integration is the process of merging development work among multiple developers. It also serves to automate unit testing and I am certain other types of testing in test driven development.

To simplify all that, it is build automation and in my opinion an automated deployment system (preferably for testing, q&a and staging).

jenkins continuous integration debian setup

Pros: Jenkins

  • Works with Git
  • Webhook from git can build/deploy/test after each commit
  • Multiple plugins available to integrate with development tools/project management
  • Web Interface...I guess this is a pro
  • Can employ scripts to run after successful builds
  • Rollback...not sure...
  • REST API

Where I have enjoyed the benefits is that if you use git for versioning and yuou are making multiple commits, there is an instantaneous test and deploy after each commit. Rather than the wasteful approach of commiting on local dev, pushing to remote, logging in to testing server, pulling from repo, testing; after every commit.

Alternatives

Theother open source alternatives are:

Setting up Jenkins Automated Deployments with your own Git Server

Haven't created your personal git repo yet? Try this tutorial or a better one.

Setting up Jenkins on Debian:

wget -q -O - https://jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
sudo apt-get update
sudo apt-get install jenkins

As far as I know that is it, provided you have apache installed...
Navigate to...

http://your-ip-address:8080/

The first thing you should do is lock down Jenkins so only you can access it

Jenkins->Manage Jenkins->Configure Global Security

Setup security as you wish, you will need to manage users for this too.

Now I am assuming you are using git for source control, if you are not you are wrong.

For a non-managed git server, ie. a private git server you have setup yourself you will need to add the git plugin in Jenkins.

Manage Jenkins -> Manage Plugins -> Install the GIT plugin

Now create an ssh key for jenkins:

sudo su jenkins
ssh-keygen -t rsa -C "jenkins@number1.co.za"
It should install to /var/lib/jenkins/.ssh

Copy the public key, of the ssh key pair.
append that public key to your git server's git user's authorizes_keys

/home/git/.ssh/authorized_keys

Should be sorted now, but hold on to the key you will need it.

Create a new item, add project name and click freestyle project.

Jenkins -> New Item -> Freestyle Project

Under

Source Code Management

Select

git

and add the git repo details along with the public key created earlier.

jenkins deploymentWhat Next

Well you build and it should be good. It builds to:

/var/lib/jobs//workspaces

So things to do and I might update this post is:

1. Setup a script to copy the build to document root (staging / live site)...but why is this required? Furthermore shouldn't the testing be done in a hosted environement, specifically end-to-end tests?
2. Setup a webhook (from the private personal git repo, and not github) to tell jenkins there has been a commit to master....

Another top article on Setting up Jenkins

k.cheers.bye.

Update:

With regards to 2. Setting up a webhook, or push based builds using jenkins take a look at the below site:

http://blog.avisi.nl/2012/01/13/push-based-builds-using-jenkins-and-git/

We need to set Jenkins up to trigger builds remotely:

trigger builds remotely scripts git jenkins

Then create a script (name it: post-receive in /your_bare_repo.git/hooks/.) with the token you just created:

I didn't need a username and password but I think it would be advisable to have a more secure method instead of jsut the token, because analytics tracking and server logs would have logged that query string parameter, and someone could potentially bombard your system with builds constantly.

!/bin/bash
/usr/bin/curl -s \

http://jenkinsci/job/PROJECTNAME/build?token=

You may have an issue with authentication, if so view the jenkins scripted clients page.

Now we may need to look at testing deployments and copying to web server if successful.