ClickOps is dead. Long live IaC!

In today's world, DevOps engineers often take on more scope in managing infrastructure. Provisioning, configuring, and maintaining infrastructure is commonly top-of-mind, but an overlooked part of managing infrastructure is managing the access to this infrastructure. After all, humans need access to do their jobs and ideally they don't have admin access to everything, all the time.

Infrastructure as Code (IaC) is relatively established and has given us the tools to manage infrastructure efficiently, but when it comes to managing access, ClickOps remains the state of the art.

ClickOps, or simply "clicking around in a web console", has given us a convenient, though toilsome way, of managing access. It's a fine approach early on, but as our companies scale, ticket-based back-and-forths combined with clicking around manually becomes costly and inefficient.

ClickOps gives us an entrypoint, but IaC gives us sustainability.

The Why

Why does this matter? Why can't we use IaC for infrastructure while keeping access managed through ClickOps? The reason is because ClickOps becomes expensive.

💸 Reduce Toil

First, we incur more development expense. Imagine having to context switch in and out of ad-hoc requests through ticketing software where your coworkers are asking for access to things. Your team is already resource constrained and you're operating on tight timelines to ship new software and maintain existing ones. For each context switch, you're taken out of your element and have to incur a warm up period before you're fully productive again. That's a lot of wasted development hours and unnecessary operational toil.

🚢 Move Fast, Safely

Second, you're often on the critical path and naturally that means you have many stakeholders with shared interest in being successful together. Not only do you have to ship and maintain software for your main goals, you have to make sure your partners in security and compliance are happy by making sure everything is properly safeguarded. This manifests in the form of building and maintaining security controls and capabilities to attest to auditors that everything you're doing fits these molds. You need to enable your users to move fast without friction while working with your security teams to ensure safety is not overlooked.

IaC already has many benefits such as making infrastructure testable, verifiable, and reproducible. These are properties that align well with access management.

IaC + Access Management = Better Together

We can reduce toil around managing access by extending IaC's existing automation tooling things we would need to orchestrate how access should be managed.

For example, see this example Terraform resource:

As DevOps engineers,

1. We should be able to define how someone should get access in a workflow containing any number of steps with each step having a number of reviewers required to approve or deny access.
2. We should be able to define policies to automatically deny access so we don't unnecessarily ping reviewers if access is denied anyway as a result of our policy definitions.
3. Once someone has access, our policies should also be able to automatically revoke access when the conditions are no longer true.
4. We should be able to output Terraform-native code using open source providers right from the Terraform Registry.
5. We should be able to pair this with GitOps and run this through our normal CI/CD to plan and apply changes anytime access needs to be granted or revoked.
6. We should be able to leverage our Version Control Systems just like any other code in our codebase so we can get an audit log of changes out-of-the-box.

But fundamentally, nothing in our normal development workflow or process should have to change.

Where We're Headed

So why hasn't access management evolved from ClickOps to IaC? The reality is that tooling and developer experience still has a long way to improve. And until we address these challenges, managing access will typically be an afterthought where ClickOps remains the default, despite all of its trade-offs. But this doesn't have to be the case. We just need the right tooling to help us along the way – tooling that comes with great developer experience and doesn't impede on the way we currently do things.

Special thanks to Emilio Escobar and Zach Wasserman for reviewing this post!