Key Management Automation with Jira

Wolfgang Joppich Fortanix
Wolfgang Joppich
Published:Jul 22, 2024
Reading Time:6mins
key management automation

Introduction to Key Management Automation

Data encryption has become critical to protect some of an organization’s most important assets: company data and PII data of customers and employees. Cloud adoption has created a sprawl of digital keys protecting various data services, with organizations losing oversight of which keys protect what data.

A Key Management Service (KMS) is essential to control the lifecycle of keys, but a strong separation of duties must control access to this service. A typical workflow for creating and distributing keys is for developers or DevOps engineers to request keys while KMS Operators generate and manage the keys.

This way, key sprawl is under control. On the flip side, this process delays service deployments, sometimes by several weeks, as the KMS operators are overwhelmed by the fast-growing number of keys. KMS operators must take the utmost care; errors may result in catastrophic system failures or data breaches.

So, the key is simplifying the work for KMS operators as much as possible. An ideal solution to automate and accelerate this process is to integrate Key Management with the Jira ticketing system.

Key Management Automation Benefits for Business

Using Jira as a frontend to a KMS in combination with a Hardware Security Model (HSM) brings several benefits to your business. Some of these benefits are:

  • Faster go-to-market with fast access to keys.
  • Regulatory compliance as keys are protected by an HSM.
  • Reduction of operational costs.
  • Reduction of human errors.

Current Situation

In many companies Developers and DevOps must request the key through email, ticketing systems, like Jira, ServiceNow, Zendesk, or enterprise resource planning (ERP) tools such as SAP or PeopleSoft. Typically, key requestors provide the following information when requesting a key:

  • Key name
  • Key type
  • Key length
  • Allowed key operations
  • Protection level
  • Project ID
  • Key location
  • Key requestor name
  • Key activation date
  • Key expiry date

The KMS operators then will transfer these details, a process prone to human errors that may result in data loss or breaches.

Key Management Automation Process with Jira

The basic use cases for managing keys through Jira is depicted in Figure 1.

basic-use-cased-of-key-management-automation-process-with-Jira

Figure 1: Basic Use Cases

These basic key creation and deletion requests trigger key creation/deletion in a KMS. Figure 2 shows a more detailed sequence diagram of the process.

key generation process for jira

Figure 2: Key Generation Process

  • The Developer starts by creating an issue within Jira.
  • The approval by the Jira Approver triggers the generation of a disabled key within the KMS.
  • Jira enables the key within KMS.
  • The KMS operator is informed, e.g., via email, and checks whether the request conforms to the internal cryptographic policies. If that is the case, they can approve the key request and the developer is ready to use it.

The process for deleting a key follows the same concept.

Configuring Jira for Key Management

Implementing the key management front-end with Jira is surprisingly simple. Jira has everything required already built in. The “Project settings” feature allows for customizing Jira. The section “Issue types” allows the creation of new Jira issue forms, such as shown in Figure 3.

 sample jira create issue form for key management configuration

Figure 3: Sample Jira Create Key Issue Form

As mentioned at the beginning of this blog, the required fields can be added to the Issue. Jira also allows you to define dropdown lists with predefined values, such as the key type. Typical values are AES, RSA, a specific ECC curve, and even PQC algorithms. In this example, the key length is added to the key type, but this could also be in a separate field.

For managing issue workflows, Jira features Workflows to define the possible issue states and the allowed state transitions. Figure 4 shows a sample workflow for the key generation and deletion processes.

sample jira issue workflow through key configuration

Figure 4: Sample Jira Issue Workflow

In this workflow, an issue for a key generation can be submitted to the Jira approver. If the issue is approved, the key will be generated. A generated key can also be deleted if the developer requests it, and the Jira approver approves it.

Now, how is it possible to connect to an external KMS? Thankfully, Jira supports REST calls through Jira Automation. The automation process is defined within so-called Jira Automation Rules, which are depicted in Figure 5.

jira automation rule

Figure 5: Jira Automation Rule

This rule defines:

  • When the issue gains the state “Created,” and the requested key type is AES 256, two web requests will be submitted to an external KMS.
  • The step between these two calls is to update the status with the response value from the first web request.
  • The so-called Jira Smart Values are used to evaluate the web response and set the variables in the web requests.

Key Management System (KMS) Configuration

On the other hand, you need a KMS featuring a REST API. With Fortanix Data Security Manager (DSM), this can be achieved easily. Just create a group for your keys and an app, which serves as the interface to Jira. Follow the Getting Started With Fortanix DSM Guide for all detailed steps. The result of the key generation within DSM will be displayed as shown in Figure 6.

key generation in dsm

Figure 6: Generated Key in DSM

The typical attributes, such as key name, key type, key length, and key description, are transmitted from Jira to DSM within a web request, and the key values are set.

It is also possible to set custom attributes, as shown in Figure 7.

custom attributes of generated key in dsm

Figure 7: Custom Attributes of Generated Key in DSM

In addition to the form’s attributes, the requestor is also taken from the Jira issue creator—in this case, the developer.

A quorum approval policy can establish the key approval workflow within KMS, as defined in Figure 2. When applied, the KMS operator will receive an email about the approval request, and when logged in to DSM, he will see a task list, as shown in Figure 8.

Quorum Approval Task List

Figure 8: Quorum Approval Task List

The KMS operator needs to validate all attributes of the key for correctness but does not need to edit any values.

And with that, we are done. The key is generated in DSM without the developer needing access to DSM and with minimal effort on the KMS operator side.

No extra configuration on the DSM side is required to establish the key deletion process.

Key Management Best Practices

The chapters above have shown how easy it is to set up Jira as a second frontend for a KMS, enabling developers to manage digital keys. However, there is more to that: Managing digital keys that protect the company’s data is the most important element within a company, and it must be handled with extreme due diligence.

For that, the following best practices are recommended to create guardrails in the system:

Automated Billing

Every time a developer or DevOps engineer creates a key, it incurs costs to cost centers or internal or external customers. Billing the key requestor is often manual and tedious. However, this billing process can also be automated if your billing solution has a REST API. Then, your billing solution can be invoked by Jira through Jira Automation just like the KMS. It only needs to be added to the Jira rule created for the key generation.

Conclusion

Automating the management of keys, secrets, or certificates in your KMS through Jira brings many benefits to businesses that prioritize efficiency. Jira can be used as a self-service marketplace, connecting developers or DevOps engineers with KMS operators. This results in reduced operational costs and less risk of human error. Jira provides everything out of the box—no programming is required.

With an enterprise-grade Key Management Service (KMS) like Fortanix Data Security Manager (DSM), your keys are secured at the highest levels. DSM follows a zero-trust-based architecture, featuring RBAC, strong authentication, custom roles, a FIPS 140-2 Level 3 certified HSM, and a tamper-protected audit log.

For more information, please contact Fortanix.

Share this post: