The webinar will be a available on demand for a year for those who miss the opportunity. I will also be using some of the content (demos) in other communication channels as well.
1 Like
-
Ensure that a playbook does not touch certain files (ie: /etc/sudoers):
ansible-policybook-examples/policy/infra/common/banned_file_modifications.yml at main Ā· ansible/ansible-policybook-examples Ā· GitHub -
Ensure that a playbook does not open certain firewall ports:
ansible-policybook-examples/policy/security/common/check_firewall.yml at main Ā· ansible/ansible-policybook-examples Ā· GitHub
For variable use cases - see is/is not defined in ansible-policy/ansible_policy/policybook/README.md at main Ā· ansible/ansible-policy Ā· GitHub
2 Likes
If you missed todays webinar about the new ansible-policy CLI tooling never fear! Itās available on demand - Automating Policy as Code for consistency and compliance
If you just want to play with the code, then checkout:
GitHub - ansible/ansible-policy: ansible-policy is a prototype implementation which allows us to define and set constraints to the Ansible project in OPA Rego language. and
GitHub - ansible/ansible-policybook-examples
^^^ Really looking forward to getting some PRs for more examples
You can also check out the recorded demo on Linkedin
Enjoy!
2 Likes
I attended the webinar from earlier today, and I must say Iām much more comfortable with the direction this is taking than I was last week.
This isnāt really a summary of the webinar (like @gwmngilfen hoped for) as much as my impression of what I heard and saw. Furthermore, this is still early days, so how PoC eventually integrates into workflows etc. will undoubtedly evolve. So with those caveats, hereās a first draft of the PoC elevator speech Iāll eventually share with my team. Itāll probably leave out details that @Phil_Griffiths and friends might consider crucial distinguishing deliverables, but I absorb new stuff in multiple passes, and Iāve only had my first pass at any concrete details. Okay, enough qualifiers.
Imagine āansible-lint for policyā. Like ansible-lint, you can run ansible-policy on individual files (playbooks certainly; I donāt know about individual task files) or on a whole project. And the console output resembles that of ansible-lint. Beyond that, though, the contrasts between them helps clarify what ansible-policy is all about.
The rules of ansible-lint are implemented in python; you tweak config file(s) to choose which of those rules are in- or out-of-play and to what degree. In contrast, Policy as per ansible-policy is defined in YAML files; no python required. People who work with Ansible YAML assets should be able to read and write their own policy definitions. Individual sets of policy files can be created, shared, mixed, matched, and tweaked to fit an organizationās requirements. They can be managed as sets of small files in logical subdirectories; you donāt have to compile or combine them into a āblack box policy blobā.
I think of ansible-policy as picking up where ansible-lint leaves off. So for example where ansible-lint encourages you to set an owner: and group: when using the ansible.builtin.template module, your locally-written policy for ansible.builtin.template could check that the values for owner: or group: come from an approved list of user and group ids. Similarly for pretty much any values in whatever context you care to specify, you can put some constraints on them. I donāt feel I have enough exposure to it yet to say anything more specific, but thatās the perspective Iāve taken away from todayās webinar. See the examples at GitHub - ansible/ansible-policybook-examples for, well, examples.
It should be fun to see how well this description holds up over time as the tool and associated technology matures.
5 Likes
Thank you Todd, that clears up some confusion I had about this initially. I didnāt attend todayās seminar, so I appreciate your write-up.
You should feed them into InstructLab and let the generative AI write some more 
This is the plan. Weāre working with IBM Research to do just that. Results are already encouraging!
Hey Todd!
Thanks for attending and the excellent write up. Right now, focussing on content creation this does very much align with an ansible-lint way of thinking. When we get into the platform functionality this will become so very much more.
Had a look at the Webinar, some thoughts.
It doesnāt feel like itās part of the Ansibleā¢ eco system.
There is some workflow issues with the way that you would want to implement policies, I like the idea that it can check code, but can that policy be run agains Infra?
Hi Karl.
The āgrand planā is to have policy content as part of the overall content ecosystem. Hopefully it can become an extension to collections.
Right now the tooling is only designed to show you the art of the possible and get feedback on use cases and policies.
The next engineering efforts are focussed around your sort of infra needs where this needs to be part of a SDL āworkflowā with suitable integration points. As well as the tooling, weāre aiming to make this an end to end experience where when creating automation content this becomes part of the flow.
Thanks for the comments!
Phil.
Thank you for the inforomation!
It helped me understand as I had wondered what the difference was between this and ansible-lint.
I just created a video on how to install ansible-policy and a simple rulebook about Policy as Code on my blog: Project Policy Validation with OPA and ansible-policy - Ansible Pilot
3 Likes
Now that I have a better understanding of what ansible-policyās intended function is, I really like where itās headed. It definitely will need a GitHub Action similar to the one for ansible-lint.
1 Like
Is this the correct place for customer to provide their feedback on Policy as Code? Thank you in advance for the feedback!
Yes it is! Please share your thoughts here in this thread.
My work group runs a clustered application that the vendor provides as stand-alone RPMs. You can install multiple versions side-by-side, and activate whichever one is supposed to be live. Saves a lot of time on upgrades, etc.
The part relevant to āPolicy as Codeā is the internal discussion weāre currently having about how many and/or which RPMs to leave installed vs. to remove, and likewise policing our local cache of RPM files weāve downloaded from the vendor. Iām not sure what the final decision on this will be, but it smells a lot more like policy than procedure. That is, uninstalling installed RPMs and removing RPM files from a cache is easy. (Too easy, as weāve found out. Donāt ask!) Choosing the right RPMs to remove would seem to me to be in the āPolicy as Codeā wheelhouse.
Iām still trying to wrap my head around how PaC intersects with automation, so specific examples like this help to clarify it. Not looking for a specific answer to this need, but rather tossing it into the idea pool to be considered as things evolve in this space.
2 Likes
We probably donāt want 100 examples in this single thread 
Weāve created the policy-as-code tag (which anyone can follow for notifications), and Project Discussions seems the right venue for such discussion. So new topics in Project Discussions with that tag are the way to go.
@CindyRuss @Phil_Griffiths if itās useful to you for wider circulation, you can use this link for people to create a new topic in the right way (good for docs/socials!)
Give it a try!
Hi Todd.
The key here would be what the rule(s) would be that would dictate the conditions for any change. How do you decide when to remove/update etc?
If you are using yum/dnf to do the operations then it would probably be based around some metadata that could be used in those modules. Otherwise, youād be calling to get approval or validation from some āexternalā system.
Have you looked at the many examples in GitHub - ansible/ansible-policybook-examples ? They should give you some ideas. Probably ansible-policybook-examples/policy/infra/os/rhel/check_pkg.yml at main Ā· ansible/ansible-policybook-examples Ā· GitHub is the base to work from for this type of example.
Phil.