Your Red Hat team is excited to have this new forum to discuss thought leadership and best practices around our vision for automated Policy As Code. We have some ideas and also want to hear from you. What do you use today to manage policies? What are your most important use cases? How can you organize “as code” to help prepare for automating policy enforcement? Let’s get the discussion started!
I suggest you start by giving this blog from Richard Henshall a read.
Stay tuned for even more news I will share around this area soon.
For the most part where I work, we have only setup Policies and a number of Security monitoring/scanning tools to provide visibility on our security posture. We use Satellite, have its inventory registered to Insights, and OpenScap policies setup (on Satellite, not Insights/Compliance) to scan weekly. There’s a handful of things we harden with code via Ansible, either as Satellite Ansible Roles or with post-provisioning playbooks.
That being said, we haven’t yet reached a point in our Infra-as-code automation to be comfortable with including Policy-as-code. To me, IaC is an important prerequisite to PaC. We haven’t been able to justify the licensing cost of AAP, so we use the upstream AWX, Galaxy-NG, and EDA-Server opensource versions. (AWX is custom built to support OCP, since we are an OpenShift customer) Our deployment of AWX is in its final phase of making its way into production and taking over some of our Ansible-related IaC practices.
Once IaC is ready, PaC will be something we’re looking to improve on (and make those OpenScap reports in Satellite happy!).
That said, we do not necessarily trust Ansible automation from outside the business, even from RedHat, so we would need to review whatever Ansible resources may come from your team. We already do this for the infra.* collections from redhat-cop, for e.g., and I’m willing to contribute code to projects upstream if it suits our business needs. On the other hand, I have yet to see an Ansible playbook provided by Insights Recommendations that I liked, but I also haven’t looked recently to see if there’s been any improvements.
Thanks for your comments! I’m the Ansible Product Manager who will be leading the charge on our automated policy-as-code initiative. This will be an AAP platform integrated feature, introducing net new capabilities to be able to enforce policies (aka rules) both before and during automation tasks.
You won’t need IaC to use PaC. They are complementary. I see you’re already doing configuration-as-code using our excellent CoP collections. It’s just the same paradigm and approach.
PaC is not designed to provide yet another answer to solutions such that OpenSCAP provides, but will compliment them in many ways. It’s designed to be much broader than that and allow you to enforce standards, limits, mandatory requirements (like change request numbers) in and around all your automation.
We’ll be covering elements of policy enforcement across the automation supply chain, from when you create automation content through to running it in production. This (with AAP) will provide customers with several enforcement points which they can choose to leverage.
I’ve listed some example use cases for various categories to give you a further idea of the type of things you’ll be able to do:
NETWORK
Any device configuration does not have insecure telnet as a connection protocol open
Cisco devices do not allow for plaintext SSH password authentication
CLOUD
If the cloud [Azure] region is allowed to be used
If the AWS instance size falls within the acceptable range (cost optimization)
SECURITY
Deny access to any database containing sensitive data from IP addresses outside the company network
INFRASTRUCTURE
Ensure all web servers in a production environment have a specific security group (SG) attached
No non-production SSH keys are allowed in production environments
No direct root access allowed to servers
This is just some of the possibilities which I hope gives you more of a feel for what this will be able to do for you!
Red Hat Summit was a great time, in part because of the warm reception we got from customers around Policy as Code. We want to get the conversation going. As you probably know about Red Hat, we like a “start small, think big” approach to new automation areas.
So in the Policy as Code space, this may be internal policies you want to enforce – such as the max size or configuration of a cloud instance or settings on your firewall. What do you have in mind for enforcing policies? Would you like to see us working with any key partners?
Check us out next week (June 18th) on our first Policy as Code webinar. We’ll explain more of our thinking and build on what we said at Red Hat Summit. Phil Griffiths and our tech marketing manager Roger Lopez are both presenting.
I want to be excited by the whole PaC (Policy as Code) idea. But, I’m going to be “that guy” for a minute:
I haven’t seen a rigorous definition of “policy”. It seems to me like it’s more of a mindset that’s somehow supposed to separate the actual “things we do” from the more lofty ideal of “the way we do things”. Somehow that doesn’t inform my fingers when I open my Editor of Choice and start to type.
Maybe I’ve hit my own personal ceiling on levels of abstraction, but I don’t see how – in actual practice – PaC differs from the same ol’ Ansible tasks we’ve been hacking on these last few years. If I really stretch credulity, I might comfortably claim that a set of tasks that truly is idempotent as a unit constitutes a chunk of PaC. But, honestly, I’d be more comfortable just claiming it’s a good set of tasks.
Truly I hope there’s more to it beyond aspirational hand waving. When I open a text file, what can I look for that clearly indicates it’s Policy as Code vs. mere code?
Very good questions and notes, and probably a good starting point for many of those that have been using Ansible for a bit. And I don’t have a lot of information about the current BU thinking. That being said this is a little description of some of the pre-work. When we first rolled this out for Large Beverage Company a couple of years ago, John Martin integrated a policy engine with AAP - “OPA”. What this provided over just doing things inside of playbooks is the ability to build standard libraries for policies. Some of the existing libraries include CIS benchmarks, PCI compliance policies etc. The initial work was providing the ability to build out policies that could be applied to all playbooks to ensure that things like tagging and basic naming conventions were followed consistently. Frankly, Policy as Code isn’t a new concept, we were going against HashiCorp Sentinel in that first account, and there are other products out there that are focused on this space But having the ability to build libraries that can be re-used for evaluating and aligning playbooks and for evaluation of the results from gather_facts etc, is what I am hoping for from the BU’s efforts. My hope is that we end up with a functional product that allows for automating compliance efforts. Automating compliance efforts would give us the ability to take a large part of the $25B compliance market, and ensure that AAP would cover 100% of our customers environments.
I hope someone will be writing a summary of that webinar too. Wouldn’t do to leave out people who can’t make it (due to timezone, work commitments, family, etc). Global communities are the best
