Automated Policy-as-Code. Start Small. Think Big.

How to get started with automated policy as code: Start small but think BIG.

A policy enforcement feature is coming to future versions of Red Hat Ansible Automation Platform. This blog provides more detail around where we’re heading with this exciting initiative.

What is automated policy as code?

Quite simply it allows you to apply policies, or in other words rules, before and/or during automation without having to know about or write those rules into your automation. You have many operational constructs you want to adhere to across your organization, and by automating them as policies, you can reduce risk, enable more operational consistency and feel more confident that you are actually operating in line with your expectations.

Why Do I Need This?

Right now, automation content writers tend to write rules into the actual automation, or declare variables for defaults or recommendations. This is a good use of automation, but limiting. It is hard to consistently enforce policies without a centralized solution. We want to provide a better out-of-the-box Red Hat Ansible Automation Platform solution.

In my opinion, no one has yet cracked the simple and effective way to operationalise policy as code. In the AI era, it's imperative that we can still enforce standards so AI does just the right things. For example, what if your AI concludes that it should create 1,000 cloud instances? What if you could have a policy check that requires approval to create more than 20 instances? Without these policy checks, what impacts would this have on your cloud operational budget? 

When you are able to design and apply the right policy checks, AI is in a better position to do its best work for you and your team. So, think of policy as code in this example as the guardrails that allow you to operate with AI.

Trusted Automation Supply Chain

The ideal automated policy as code solution will allow you to write all your rules as simply as possible, then ingest them from a source, and apply them at the relevant points and times to your automation needs:

You need to  be able to check policies at all automation stages and across your operational lifecycle. We tend to use these categories to help explain this:

Create. When creating automation content, check for relevant policies whilst in the editor or during CI/CD software development cycles. This “shift left” exercise will help maintain consistency and plug potential problem areas at their source, before they can have ripples and implications across your environment. Over time, we’ll utilize AI capabilities to make this even more relevant and easier.

Manage. Automation is now becoming mission-critical due to the need to move fast, the complexity of your existing hybrid cloud environments, and now comes AI sprawl to add even more demands. You need automation to meet all of these demands. Yet at the same time, you still need to ensure all of this operates within the bounds of any governance, risk and compliance (GRC) measures we need to adopt, whether they are internally-designed or externally mandated. This requires a centralized automation platform like Ansible Automation Platform.

Scale. It’s important to know what’s been done and the current compliance state so you can consider what changes or controls can mitigate potential issues. You need an audit trail of events, changes and compliance to keep auditors and regulators informed.

Ansible Automation Platform Runtime Enforcement

Great automation complements and fits into existing business processes. Change control management systems or mandates that certain conditions have to be adhered to for any change are very commonplace.

This is why we plan to introduce a global level enforcement mechanism to simplify operations when you also have to meet certain requirements.

What if you had a universal way to:

• Enforce the need for an approved change number before running anything?
• Not allow automation during maintenance windows or moratoriums without some form of approved exception?

These are the kinds of actions we’ll allow you to implement at a global level.

Beyond this, your automation policies need to be applied consistently, have relevance and context. This is a mechanism like an automation job runtime that could allow for further granular control and measures. This design could also provide attribute-based access control (ABAC) functionality to compliment the platform's current role-based access control (RBAC).

What Could I Start With?

Anything! But we advise, in true Ansible fashion, to start small and work up, whilst thinking of the bigger picture at the same time.

Let’s break this down as an example, using a cloud-based services use case. Let’s say you operate a two-cloud operating model across AWS and Microsoft Azure. You deploy all types of services and applications across these platforms in various locations. You want to ensure that standards are applied so you can stop cost escalations and always meet your security recommendations.

Looking at this from the top down, it seems to be a formidable, lengthy and complex set of challenges. But let’s start small and extend out to ultimately achieve the bigger goal.

Different cloud providers offer different ways to do things. This isn’t ideal as there is often no single standard. This is where Ansible Automation Platform comes in as a highly flexible and agnostic common automation tool with rich and extensive content collections that help you jumpstart the type of automation you need. If we can wrap all of this in a policy as code automation model, then this becomes very powerful with the enforcement you need to control costs and stay aligned on security measures.

Go for quick wins with some of your most common challenges, for example::

• Stop unfettered cloud instance size choices by developers
  • Could be a rule to only allow certain size choices
• Stop wide open public access points in their tracks
  • There is no rule ensuring ANY/0.0.0.0 type ACLs are used
• Only approved, tested OS and application packages are installed
  • The use of ‘latest’ isn’t allowed and version choices pinned

Straightaway, if you can nail these if you have:

• Introduced measures to stop poor choices and potential cost sprawl
• Stopped ‘lazy’ options being able to open up easy attack entry points
• Improved application stability by ensuring the right software is used

These types of policies exist already and we have already demonstrated how this can be applied at a central automation platform level. We are now working on making this a simple but highly effective feature to take policy enforcement to the next level. I will be hosting a webinar on Tuesday, June 18 so you can learn more about our vision for automated policy as code. Register here or visit this web site for additional information:  _redhat.com/PaC_        

Get In Touch.

Want to know more? Got some burning questions or use cases you want to explore? Want to tell us what your needs are and explore use cases along with us and other customers? Head over to our Ansible Forum which is our policy as code advocacy group where we’ll be hanging out, excited to hear more! 

If you are a partner, we would love to talk to you. Technology partners may wish to codify their best practices into automated policies, with content collections greatly benefiting our joint customers. System integrators may wish to include automated policy as code services in existing or new services. Speak to your Red Hat contact or reach out to us via a specialized policy as code partner forum.