In this article, we’ll demonstrate how to automate the provisioning of AWS Accounts via self-service using Jira Service Desk, potentially reducing the provisioning time of our AWS Accounts from 4 hours to 25 minutes.
With more than 5 million articles from over 7,000 brands, OTTO is one of the leading German online shopping platforms. In the future, it will open up to even more brands and partners as part of its transformation. OTTO is part of the internationally active Otto Group, with headquarters in Hamburg, and employs 6,100 people throughout Germany. In the 2020/21 financial year, OTTO generated revenues of 4.5 billion euros.
At OTTO, we faced several challenges to set up a scalable multi-account environment in AWS. We must govern several hundred AWS accounts for our product teams, all while balancing the need for agility and control. At this scale, the cloud setup and governance can be complex and time consuming, the onboarding of product teams and new environments must be accelerated, and manual steps should be reduced to a minimum. All of this is done to increase agility and decrease the rate of errors, while being fully integrated into the enterprise environment, via approval processes with SIEM-integration. SIEM, or security information and event management, is a field within computer security combining security information management and security event management products and services.
The cloud competence center at OTTO IT, also known as the Governance at Scale (GAS) team, built a serverless self-managed landing zone that is integrated in the OTTO tooling ecosystem with Jira Service Desk and Quest One Identity Manager. The solution allows product teams to provision new AWS Accounts via a self-service portal in Jira Service Desk, while the central GAS team provides pre-approved, secured, and governed AWS accounts that conform to company policies. The integration with Jira Service Desk enables the central team to track resources and configurations and maintain visibility into the compliance status, as well as provide the product teams with documentation to accelerate product team onboarding.
OTTO worked with globaldatanet to set up its Landing Zone. globaldatanet is an award-winning AWS Advanced Consulting Partner and longtime Cloud Solution Provider for OTTO, supporting the team in cloud security and GAS. Their focus on building cloud-native solutions using Serverless supported over 100 companies within 5 years to develop and innovate products and services in the cloud.
As already said, we’ll demonstrate how to automate the provisioning of AWS Accounts via self-service using Jira Service Desk, potentially reducing the provisioning time of new AWS Accounts from 4 hours to 25 minutes. The solution workflow includes the following steps:
Let’s see how this works.
The following prerequisites are necessary for following along with the contents of this post:
The following architecture shows the whole solution of the Account Vending Machine. In this post, we focus on the Jira Service Desk Integration, highlighted in green.
We decided against utilizing a plugin to reduce dependencies/constraints, especially with a focus on Jira Cloud. Fortunately, Jira offers everything that we need to build our own solution.
Request types let you define and organize incoming issues. Create a new Request Type dedicated to request new AWS Accounts. To make it easier for customers to find what they need, additionally create a group “Account Vending Machine” in which these request types are organized.
The request type is based on the Issue Type “New Feature” and is provided by the OTTO-Jira-administration team. The workflow used is the standard “open”=>”in progress”=>”in validation”=>”closed”-configuration.
Note that you should restrict access to the Jira Request Type to a limited amount of resources having a business role within your enterprise to allow the request of new AWS accounts.
Especially in large environments, it’s an additional effort for Jira admins to create new fields for every use case. We circumvented this by reusing existing fields and setting a “display name”.
After setup is completed, the customers’ view on the support portal is as follows:
As soon as the required fields have been entered and the Create button is selected, a new request is raised.
Note the field “IT-Shop Approvers”, which is very important later on. The field is based on Jira’s “Person Picker”, which lets you fetch persons from Jira’s directory, which in our case is synced against the corporate Active Directory.
Process wise, we decided against full automation, thus enabling us to briefly check the quality of the entered fields before letting the Jira Automation kick in.
Jira automation rules let you perform actions based on specific triggers and conditions. In our case, we want to approve the request and send the populated fields from the new AWS Account Request to trigger the account creation in AWS.
This automation rule will apply the following action, after a customer creates a new AWS account request:
Jira Automation uses a combination of “WHEN”, “IF” and “THEN” to automate tasks.
The next requirement of the architecture is the API receiving our payload, for example, ”something” we could use as a Webhook URL.
The obvious solution was to use API Gateway.
It takes care of the authentication by evaluating the API-token delivered in the header and, if successful, using the Lambda integration to hand over the payload as received from Jira. See here how to set up an API Gateway with Lambda integration.
Due to the information needed for the account-vending-machine, you can’t avoid custom fields in Jira. These fields aren’t named the same as you see within the Jira configuration. Instead, they use the format “customfield_xyz” within the payload.
To identify the fields that you need for the processing, we’d suggest populating a ticket with easily recognizable values, and then use a payload dumper such as this (or your Lambda) to check the payload for the field keys that you need.
As an alternative, you could use the “Inspect Element” function of your browser while having the JSD-ticket opened.
In our case, as shown in the ticket’s screenshot, we’re using a couple of fields, for example “E-Mail Address”, to request the account’s contact email. This field is in our OTTO-specific Jira environment identified as “customfield_12949”.
As soon as all of the necessary fields are identified, use Lambda to process the payload. Depending on the programming language that you use, you can either address them directly in Python or transform the JSON into a data object.
As soon as this is done, we suggest using Lambda for preprocessing the values, for example, making sure that there are no leading or trailing whitespaces or convert upper to lowercase.
Finally, the Lambda uses AWS SDK to trigger a new codebuild-project run, while using the variables fetched from the payload as environment variables.
The Account Vending Machine Backend consists of AWS Systems Manager Parameters, an AWS CodeBuild, a few Lambdas, and an Amazon SES. Instead of using a Lambda function for the main logic like the Account Vending Machine, we decided to use CodeBuild because we had some pitfalls using Lambdas.
Here are some problems we solved during the development:
As the backend is highly dependent on your setup, we’ll keep this in a black box. However, we took some routes you also could learn from:
To send the Account creation status back to Jira Service Desk, we’re using an email which is sent through the Amazon SES Email API to the Jira instance. We verified the whole domain of our mail server to be able to send mails from different team members as the Account Vending Machine. That way, the requester knows who invoked the Account Vending Machine. In addition, we’re using DKIM to sign an email with a private key to verify that parts of the email haven’t been modified during the transit. The Amazon SES deployed is a second tools account, and we can use this SES configuration for all of our governance tools.
We decided to use the email API of Jira because we already have experience with that API, and few of our other services are already using that API to send information back to Jira tickets. In the future, we’ll move to the Jira API with all of our services.
The email body is constructed in the Account Vending Machine with relevant information about Account metadata, links to access the AWS Account and Billing Dashboard, onboarding documentation for the product teams, and deployed security guardrails. The email updates the corresponding Account Request Jira issue, so the product team can quickly start working, while the central platform team has a configuration history and tracks changes.
The Assignee of the ticket is used as the email’s sending address, thus resulting in a more personal view, as Jira uses their identity for the comment. The important thing while sending the email to Jira is using the Ticket ID as the subject, that way the comment is mapped to the ticket.
The teams are presented the following view in the Jira Service Desk AWS Account request:
In this post, we demonstrated a solution to integrate Jira Service Desk with an Account Vending Machine in AWS. The solution offers a self-service portal in Jira Service Desk for product teams, and the provisioning time of new AWS Accounts could be reduced from 4 hours to 25 minutes. By providing relevant information like Account metadata, as well as quick access to relevant accounts, dashboards, and documentation, the onboarding time of new teams could be reduced by the same amount. Simultaneously, the operational efforts of the central cloud platform team were reduced. In the Account request, the team tracks resources and configurations and maintains visibility into the compliance status, which improves governance and leads to an increased security posture.