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?
