Blog

We want to inform that our DevOps Helpdesk number has changed.

  • new number: +49 69 9731799115

Our old number has been replaced by the new one.
The number is available since 25.03.2021 and occupied between 08-18 CET.

Beginning at next week we start the initial rollout of SSO for most of the customers. This initial rollout includes the deployment of the basic infrastructure and providing SSO for the Atlassian tools Confluence, Jira and Bitbucket.

Some of the preparation work can be done in the background, but to reconfigure the tools a maintenance window is required. The affected customers are going to receive corresponding maintenance tickets for information and approval of the maintenance work for SSO.

When SSO is enabled for a specific tool, then the login doesn't occur locally in the tool anymore. The user is rather redirected to a central login page, which performs authentication centrally on behalf of the tools. As a result, login must only be performed once and the established authentication session also automatically authenticates a user against the other tools. 

The Password Reset function remains unchanged, there is a link at the login page which refers to the reset page.

2-Factor-Authentication (2FA) is prepared and can be configured on demand per User. If a customer wants to have 2FA for users activated, then it's performed based on a Service Request for the defined list of users. We decided against to enforce 2FA for all users, because there are side-effects for technical users possible. There is already a user story in our backlog to integrate 2FA per user in the self-service-portal.

Technical users for the Atlassian tools have already been stored locally in the tool. This remains unchanged with SSO. As a consequence, technical users can still use the Rest-API with local authentication (unchanged) but can't login to the Web-UI anymore. When SSO for Jenkins is going to be rolled out, then there are some preconditions required regarding technical users.

To provide SSO as early as possible and to minimize risks during migration we decided to rollout SSO step-by-step for the different tools. So, the initial rollout includes Confluence, Jira and Bitbucket. In a next step, the self-service portal and Jenkins will be added. GitLab and Rancher will be added at the end. Due to technical reasons, Nexus is not going to be included in SSO. This should not be an issue, because there is only a seldom requirement to manual login into Nexus.

We think, that the introduction of SSO is a significant step forward making DevOps-as-a-Service a better and safer product.


We just published a new page, which gives our customers a better transparency regarding:

  • Information to the latest release of the self-service portal (release notes)
  • Information regarding planned improvements and enhancements (release planning)
  • Information about other enhancements and new features, planned for the next months

All those information can be found here: Release Notes and Planning

We suggest to watch that page to keep informed in case of an changes.

The Project DevOps as a Service as well as the included System SDCLOUD Release 1.0 have passed the PSA process. These are the official identifiers used in the PSA process of Deutsche Telekom Group for the product DevOps-as-a-Service.

The Privacy and Security Assessment (PSA) process was introduced to ensure compliance with security and data privacy requirements in development projects. It regulates support and advice from security and data privacy experts – Project Security Manager (PSM) and Data Protection Consulter (DPC) as well as the security and data privacy approval of the systems.

The process has three main objectives:

  • A consistent and adequate security and data privacy level in all products, systems and platforms that have to be updated or created from scratch.
  • A support level adapted to project complexity and criticality through the introduction of categorization at the start of each development project.
  • An integrated process for information security and data privacy as part of the product and system development process (to avoid redundancies in the approval process).

The process can be used on all IT and NT systems, regardless of size and complexity. It ensures greater transparency, improved project support and an adequate level of protection for products from the Deutsche Telekom Group.

Please see the PSA Booklet for more information:


The new version v2.7.1-11 of the Prometheus Global Stack was just released. This version contains the following highlights:

  • The Blackbox-Exporter is included again, to be an integral part of a global monitoring solution
  • Configuration file for Blackbbox-Exporter is located on a persistent volume and can be adjusted to individual needs
  • prom-conf helper container now includes some useful editors like nano and vim to edit the config files more convenient
  • Some other improvements, see Readme file

Before upgrading existing stacks, customers must check if a Blackbox-Exporter service has already been integrated manually.  If this is the case, then please note:

  • If the existing exporter has been named "blackbox-exporter", then it would be overwritten by the catalog update.
  • If the existing exporter has a different name, then a second exporter would be installed into the stack during upgrade. Migrate your existing config (see next point) and change the hostname for the exporter in Prometheus config to "blackbox-exporter:9115". Afterwards manually delete the old exporter from the stack.
  • An already existing adapted persistent config file wouldn't be overwritten during the update. But the new exporter from the update would use the config file under /etc/prom-conf/blackbox.yml within the blackbox container. Thus ensure, that your existing adapted config file is moved to /etc/prom-conf/blackbox.yml within the blackbox container.

If there are any questions, please contact the DevOps-as-a-Service support via Service Desk.

We would also like to refer to the renewed Monitoring Documentation.

IAM 1.0.0 released

This week we started to roll-out IAM (Identity and Access Management) 1.0.0 for our customers.

New Features

Global Licence Management

For each user, ADMINs can now decide which licenses should be assigned and which not. This helps you to save licences as some users may not require access to all tools. The feature is available using the Edit User menu item as shown below:

Access to Open Source Tools is always granted since no licence costs are involved.

ServiceDesk is an optional commercial plug-in to Jira. It's now possible to use the self-service portal to assign or unassign ServiceDesk licenses to your users that are working as agents for your service desk. From the user perspective you already know ServiceDesk since we are using it ourselves to offer you the best possible support for your DevOps-as-a-Service instance.

Helm Chart Repositories

As you will see in Nexus we added support for Helm Chart Repos. So for each project created by the self-service portal there's now also a Helm Chart Repo in addition to the existing Maven2 Repo and the private Docker Registry. Since Helm Repos share the same namespace with Maven2 Repos the suffix -helm is added to the Project Key. See below the showcase project as an example:

Further Improvements

  • Added support for Jira v8 auto-provisioning

  • Prepared support for connecting to customer's ActiveDirectory or LDAP-Server.

  • The Audit log is now sorted with last entries first by default.
  • Navigation improved on some pages
  • Security was increased a lot.
  • Several bugs were fixed.

Known Issues

In the past, users received a licence when they logged in to Jira, Confluence or Bitbucket the first time. This is now done instead by the portal when a user is created. It can be that you have users that never logged in to Jira, Confluence or Bitbucket and therefore never received a licence inside the application. Therefore they will not be able to login now to these tools. To repair this, simply remove the licence from the affected user and save. Then add the licence again and save.


We're proud to announce that our product DevOps-as-a-Service is now officially promoted on https://cloud.telekom.de/de/infrastruktur/devops-as-a-service. We managed to get the German version published before christmas and will add the English version beginning of 2020.

If you use the menu on https://cloud.telekom.de/ simply go to the Infrastruce as a Service menu and select one of the six detailed pages that we currently offer for DevOps-as-a-Service. A contact form which you can use to Order DevOps-as-a-Service is also available.


We whish you a Merry Christmas and a Happy New Year!