DevOpsKube – Redmine SSO with KeyCloak via OpenId Connect

Because we could not make the logout functionality work using the SAML Plugin of Redmine (see last post), we decided to use the OpenId Connect Plugin. Due to the fact, that some functionality (eg. SSL Validation was always enabled, which is not wanted in Development Environments) we have forked this plugin and implemented some fixtures (see here). Those fixtures are already commited to the original project as Pull Requests. As soon as those are merged, we are going to use the original version instead of our fork.

Obviously DevOpsKube is not interested in a manual configuration of this SSO connection, but some documentation is always helpful. Unfortunately we haven’t found any documentation about the Integration of Redmine and KeyCloak via the OpenId Connect Plugin, therefor we do provide some additional documentation about this integration on our DevOpsKube Documentation. The Integration is already commited into our Repositories, but there is still some work to do on the KeyCloak setup (we do need to implement keys, which are used in Redmine as well as KeyCloak). As soon as this is done, we have implemented the first full integration between two components of our DevOpsKube Stack.

Hope you do find this helpful. If you would like to support us, in building up a modern SDLC stack on Kubernetes, do not hesitate to join our effort.

Redmine SSO with KeyCloak via SAML Protocol

For the DevOpsKube-Stack we are currently implementing a Single-Sign-On (SSO) solution for Redmine. For this we do use KeyCloak as the Identity Provider and the SAML Protocol using the Redmine Omniauth SAML Plugin. Unfortunately there is just the sample initializer found on the Plugin, but not any additional information. Therefor we do describe some steps on how to get this to work, for your own enjoyment.

  1. Install the Redmine Omniauth SAML Plugin like described on their README
  2. Create a client in your Keycloak Server. we have named it „redmine“
  3. Create Mappers in your keycloak for the redmine-Client using the following properties:
    1. Name: firstname, Type: User Property, Property: firstName, Friendly Name: givenName, SAML Attribute: firstname
    2. Name: lastname, Type: User Property, Property: lastName, Friendly Name: surname, SAML Attribute: lastname
    3. Name: email, Type: User Property, Property: email, Friendly Name: email, SAML Attribute: email
  4. Now the saml.rb file (see Sample File) should be configured like the following:

    Redmine::OmniAuthSAML::Base.configure do |config|
    config.saml = {
    :assertion_consumer_service_url => "http://REDMINE_URL/auth/saml/callback", # OmniAuth callback URL
    :issuer => "redmine", # The issuer name / entity ID. Must be an URI as per SAML 2.0 spec.
    :idp_sso_target_url => "https://KEYCLOAK_URL/auth/realms/REALM_NAME/protocol/saml", # SSO login endpoint
    #:idp_cert_fingerprint => "certificate fingerprint", # SSO ssl certificate fingerprint
    # Alternatively, specify the full certifiate:
    :idp_cert => "-----BEGIN CERTIFICATE-----\n...\n-----END CERTIFICATE-----",
    :name_identifier_format => "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent",
    :signout_url => "https://KEYCLOAK_URL/auth/realms/REALM_NAME/protocol/saml/clients/redmine", # Optional signout URL, not supported by all identity providers
    :idp_slo_target_url => "https://KEYCLOAK_URL/auth/realms/REALM_NAME/protocol/saml/clients/redmine",
    :name_identifier_value => "mail", # Which redmine field is used as name_identifier_value for SAML logout
    :attribute_mapping => {
    # How will we map attributes from SSO to redmine attributes -- custom properties
    :login => '',
    :mail => '',
    :firstname => 'info.first_name',
    :lastname => 'info.last_name'

    config.on_login do |omniauth_hash, user|
    # Implement any hook you want here

Right now, the logout is not working properly, but we do still work on this one. As soon as this integration is finished, we are able to provide the first „real“ integration for DevOpsKube.

If you have any further questions, do not hesitate to ask in the comments.

DevOpsKube: New Homepage

We just updated our homepage, which is now reachable via the newly registered Domain This homepage is fully generated from the README files of the charts as well as some additional Mardown-files.

Please have a look on this new Page. Any contributions are highly welcome.

DevOpsKube: Lots of updates

We updated the docker Image of jenkins to reflect the latest changes on the MySQL Docker Image (eg. we added the Makefile, a jenkinsfile and use the latest Version Bump Stuff. These new versions of the Image are now also reflected in the main DevOpsKube charts.

Furthermore we updated the Single-Node user-data to use the latest Kubernetes Version (1.4.6). This adoption is in order to reflect the changes found in the CoreOS Single-Node repository.

Next steps are now to use a seed-job for the Jenkins Docker Jobs we do have right now (mainly: docker-mysql as well as docker-jenkins) and to then integrate jenkins with our local Gogs chart, to be able to provide a fully working Docker Building in our SDLC stack.

If you are interested in our efforts, please join us. Any help and any contribution is welcome.

DevOpsKube: Make Jenkins build Docker Images

We did add the possibility to build Docker Images using Jenkins in our latest update of the Jenkins Chart. You can use a Jenkinsfile to configure the Image-Build-Job (see Docker Mysql). This script shows pretty easy, on how to build the docker image like it is done on the Docker-Hub Automatic Build. Basically this script checks out the Git-Repository, builds the Image and checks if the latest commit is a tag, and if so, tags the image accordingly. In each case the Image is then published on Docker Hub using the tag „latest“.
To make the tagging working, we do use the python script BumpVersion. To see how this works, you can take a look into the Makefile of this project.

DevOpsKube: Using static files as input for ConfigMaps

For some of our charts in DevOpsKube we wanted to use static files as a template, obviously still be able to use Variables from helm (eg. .Release.Name). This seems to be rather easy, looking at the „include“ statement of helm. Unfortunately this is not really well documented and/or not working as expected. Some projects (eg. SAP CC-OpenStack do use this feature as well. I did try to use the same logic, but unfortunately this was not working (with helm 2.0.0-rc1 at least).

Here are some guidance on how to implement configmaps in kuberentes using helm and static files. First of all, all static files are put into the /etc-directory. These files are not recognized from helm by itself, therefor we do need to create a Partials-Template (named: _partials.tpl). To do this automatically, we added a Makefile, like the one found at the SAP-CC solution. If you then type „make“ in the corresponding chart-directory, a templates/_patials.tpl file is generated, which contains all static files in a corresponding „define“-structure. This file is ignored by git.

To reference the structure in the configmap, it can be included by using the following structure:

{{ include "etc/FILENAMD" .| printf "%s" | indent 4 }}

For a working example of this, please take a look into our jenkins chart.

Howto install a kubernetes single node „cluster“?

We just published a documentation on how to install a single-node „cluster“ at my preferred Hoster. This documentation describes, on how to install [coreOS]( and initialize the single-node cluster on this node.

This is really helpful for „testing“ the DevOpsKube Environment, but could be also used for small projects.

The documentation can be found in the github Repository.

DevOpsKube – Just launched…

The first version (the components mentioned in the roadmap for version 0.1 are implemented) is now published on our github page. The site is now reachable via

It would be great, if you come by and contribute to this new and interesting project. Every contribution is greatly welcome.

DevOpsKube – My opinionated View of a full SDLC Stack on Kubernetes – Roadmap

It was decided to use the following Roadmap to be able to provide some useful Components already and to have something to extend on.

Note, that this roadmap is not fixed yet and it could be, that some mentioned features are coming in later versions. This roadmap should just describe the rough idead where DevOpsKube is heading to.

Version 0.1

All Components mentioned in the first post should be provided using MySql. Furthermore the configuration for these components is provided and docaumented. All necessary steps to setup a single node cluster (based on CoreOS) will be documented as well.

This will be a pre-liminary version to provide all the components and steps to build up the future „development“ environment.

Version 0.2

Add additional components to the Stack to provide a fully featured SDLC Stack. These components could be:

Version 0.3

Add additional components for eg. SSO and other things, which can be useful in an SDLC Stack:

This version should already provide SSO functionality for the defined components.

Version 0.4

Additional functionality to be able to create projects via a single REST-API call. This is the first version with some unique functionality. The REST-API should include a web-based client as well as a Command-line client.

Version 0.5

Make all of the components (if upstream allows) HA-able. Furthermore integrate those as much as possible.

Version 0.6

Be self-hosted. We should eat our own dog-food, therefor we should host this project on our own Kubernetes Cluster.