There are so many tools, so many things to learn. It’s hard to imagine that any DevOps project actually gets off the ground given the numerous skillsets and knowledge required. Practitioners must not only learn about the cloud, which types of infrastructure to spin up, how to spin it up, but also how to effectively secure that infrastructure. Dealing with TLS certificates in DevOps is a security challenge that many can relate to.
In looking at Stack Overflow, for instance, the number of questions related to securing infrastructure number is the tens of thousands:
- OpenSSL (11,100+)
- SSL/TLS (37,800+)
- Encryption (28,500+)
Questions that come up may include, “How do I generate a certificate?” “How do I secure my containers?” “How can I secure inter-service communications?” And “What’s the easiest way to automate the process for certificate renewals?”
Yes, questions on Stack Overflow may not be in plain English, but at the end of the day, developers need answers to not just these questions, but they also need solutions that work seamlessly across all their environments. To fit DevOps speeds and best practices, some even say a solution needs to be easy enough to be implemented in less than 5 minutes. Otherwise, it’s too complicated or time consuming and developers will look elsewhere. Absent a solution that automates certificate lifecycle management, what are the prospects for fast, efficient integration of this important security activity into DevOps environments? It’s a grim outlook.
Outdated paradigms are so painful
Think back to pre-Google Maps (before 2005): getting from point A to point B required some planning, time, and lots of uncertainty. First, you may have had to look up the address of where you wanted to go (in the Yellow Pages!?). Then you may have looked at a map and hoped it was obvious enough to plot out your route, guessed at how long it might take you, and hope you didn’t get lost enroute. The thing is, you still needed to get from A to B, so the extra time and risk spent on the task was not only a necessary evil, but a a commonly accepted paradigm. So, how does this relate to certificates in DevOps environment?
Today, many enterprises continue to use outdated paradigms (aka, ticketing systems) for certificate issuance. This is painful, and slow.
The current state of certificate provisioning within DevOps also poses a variety of challenges:
- Certificate provisioning is not embedded into software-defined infrastructure.
- Development teams are unable to easily comply with policy.
- Information security, risk and governance teams have little visibility into certificates.
- Certificate-related outages continue to plague organizations.
Due to these challenges and inefficiencies, it might take days for a certificate to get issued. Meanwhile, DevOps teams must wait and frustrations continue to escalate. This antiquated process of certificate issuance won’t stand and change is needed.
The new approach demands automation
Automation. Automation. Automation. That’s what DevOps teams thrive on and require to be successful. It’s an easy concept to describe but hard to implement and standardize across environments, especially if you are a DevOps practitioner who is given the mandate to comply with security policies. Most readily available automation solutions don’t enforce security policy, and while helpful for DevOps teams, they are a cause of frustration for InfoSec teams. Proactive InfoSec and development teams know that the security policy should be treated the same as any application code—it should be defined as code, versioned as code and tested as code.
Taking a programmatic approach allows for “baking in” trusted certificates into DevOps continuous integration/continuous delivery (CI/CD) pipelines – using a standardized REST API that abstracts away certificate issuers -- is the new gold standard. If this is done within the existing DevOps toolchain, where developers can continue to use their existing tools, we establish a whole new paradigm for injecting machine identity protection into DevOps workflows.