How policy as code imbues DevOps with speed & protection

Transcript

Mitchell Hashimoto: One of the biggest challenges that policy as code or compliance as code solves is the challenge of almost too much automation. You want to automate as much as possible, but let’s say you ask to create 5,000 servers. If you had to fill in an order form that someone actually looked at, they would be like, “This is probably wrong.”

But when you tell a machine to create 5,000 servers for you, it just goes ahead and does it. And that could be a really expensive mistake. And so policy as code or compliance as code is a way to codify these hard limits, those extreme levels, but also more nuanced limits. Do you have examples of good policy as code?

4 use cases for compliance as code

Armon Dadgar: I think there are 3 categories of policy as code:

• Operational best practice
• Security-type controls
• Compliance-type controls

Operational best practice might be, “Don’t deploy 5,000 nodes.” But it might also be, “Don’t deploy after 5 PM on Friday,” where there’s no compliance rule that says don’t, but just don’t do it. Don’t deploy on a weekend.

A security best practice example is, “Don’t open the firewall to allow all traffic.”

And a compliance requirement might be, “The PCI database is only accessible in the PCI network zone.”

Mitchell: A fourth is the education use case, which I think is really cool: creating policies that help educate the user. “You requested this type of instance, but this type of instance is usually better for your workloads.” You can use these policies that don’t fail the operation to teach more junior people how better to use infrastructure, which is a really cool use case.

Armon: Yeah, nudging people into the right behavior rather than just saying no.

Otherwise, what we see all the time is: “Here’s an endless series of text to read—don’t use this instance type; do this thing; don’t forget this thing.” But if you have it as policy as code, the system nudges you the right way, and you don’t have to read these massive tomes and try and remember everything. This just tells you, “By the way, you use this other instance type.”

Mitchell: Policy as code doesn’t have to be the Department of No.

Policy as code vs. people as policy

Armon: That brings up a good point. What you see if you don’t have policy as code is people as policy. You file a ticket and then wait for someone to manually go through your change and review it, and then you wait days, weeks, months. When it’s policy as code, it’s the same control ultimately, but it’ll be, “Please wait 3 seconds,” and then the engine comes back and says yes or no.

Mitchell: It’s interesting because it’s easier to get the “no” feedback from a machine than it is from a person. You want the machine to automatically tell you, “This is out of compliance.” For some reason, it’s an easier piece of feedback.

Armon: Not a conversation.

Mitchell: Yeah.

Armon: It’s like an email or something.