candidate: F5 Event Driven Security

[VDI-Tech-Guy]

Candidate Name

Event Driven Security with F5

Link to Github Repo

https://github.com/f5devcentral/f5-bd-ansible-eda

Review Due By

April 17, 2024

CHECKLIST

Business Checks:

Content Viability

• [x] isn’t just a demo
• [x] must support a “business-viable” use case
• [ ] is production-ready, as in able to run in Ansible Controller “as-is”
• [x] provides a solution an end-to-end automation use case and brings value to our customers

Content Duplication

• [x] use case addressed by the content isn’t covered by another validated content collection already - to the best of our knowledge

Technical Checks:

Content Conformity

• [x] is packaged as a content collection - see the Collection Requirements Checklist
• [x] is YAML only (Exception: if plugin(s) included are necessary for this specific use-case and are not generic enough for a certified collection)
• [x] if there is a plugin(s), it is not a duplicate of something from a certified or supported collection - to the best of our knowledge
• [x] supported plugin/module used in a validated role is noted as a dependency

Content Compliance

• [x] no known policy or legal reason for why the content shouldn’t be published
• [ ] README contains information about the purpose of the collection and how to install it
• [ ] README contains a link to the collection license file
• [ ] README contains general usage and requirements information such as required versions of ansible-core and Python, and other required libraries or SDKs
• [ ] install / requirements.yml information all points to Automation Hub, not a Github repo
• [ ] Repo is self-certified with the OpenSSF Best Practices and has the OpenSSF Best Practices Badge
• [ ] Has 2 or more active maintainers listed in a CODEOWNERS file.
• [x] Has an approved OSI license
• [x] Content falls logically into one of these domains - infra, security, network, cloud, edge
• [x] (If internal content) Content has been or is being migrated into the redhat-cop Github org

Content Testing/Validation

• [ ] runs ansible-lint “Production” profile in an active Github workflow on the repository
• [ ] passes the ansible-lint “Production” profile
• [ ] ansible-lint.yml file (if present) only contains justified ignores - with a comment explaining the need for each ignore

Emily Bock recommended me to following this path please reach out to her for questions

[alisonlhart]

Hello @VDI-Tech-Guy! I've started the preliminary review for this collection. This will be presented to Red Hat's Automation Community of Practice as a validated content candidate. That group will have 2 weeks from presentation (initially presented on April 3, 2024), to review the collection and add feedback. This will have a final sign-off date of April 17, 2024.

There are a number of changes that should be made before this review starts. A few are detailed below, from the checklist: - isn’t just a demo One of our requirements is that a validated content collection is not just a demo. The language in the README indicates it's a demo and not meant for production usage. If the language can be modified to indicate that these are templates meant for customer use and not just for demonstration, that will meet this requirement.

- is packaged as a content collection - see the Collection Requirements Checklist The content submitted is missing collection structural elements like a galaxy.yml file and meta/runtime.yml file. It will also need a changelog file.

- supported plugin/module used in a validated role is noted as a dependency There are a number of collections used in the playbooks that aren't noted as dependencies. These will need to be listed the galaxy.yml file's "dependencies" list.

There are a number of other missing requirements detailed in the checklist. Please go through it and ask any questions as needed.

Here is an example validated content collection for helpful reference: https://github.com/redhat-cop/network.backup

[alisonlhart]

@VDI-Tech-Guy Hello! Have you had a chance to look at the review feedback above?

[VDI-Tech-Guy]

Hello @alisonlhart - I have done some updates to this to reflect the asks, however due to this being Event Driven Ansible related code mixed with Playbooks im uncertain of a example that be provided to make this a collection, and am uncertain if that is even possible in this usecase as EDA as far as i know is not made into collections (rulebooks) etc. Could you look at the provided changes and chat with Emily Bock about this as im uncertain what else needs to be modified for EDA + AAP Validations.

[alisonlhart]

@VDI-Tech-Guy Here's some documentation on EDA generally, which links out to more detail of EDA collection structure requirements. The overall structure is the same as a collection without EDA content, but adds EDA content under the extensions/eda/ dir.

Here's an example of a collection that contains EDA content for reference: https://github.com/ansible/event-driven-ansible

Rulebooks should be contained under <collection_root>/extensions/eda/rulebooks/, while playbooks can remain under the standard structure of <collection_root>/playbooks/.

Let me know if you have any other questions or need additional examples!

[VDI-Tech-Guy]

@alisonlhart I have updated the repo with fixes and the help of Chyna to resolve some of the problems in the code, she said it now builds correctly and i have gone through and updated Lint checks, there will be 1 error that cannot be resolved

yaml[line-length]: Line too long (396 > 160 characters). in playbooks/bigip-classic/block-ips.yaml. this is due to the code thats being injected is XML Formatted and has to be a specific way for this to work correctly.

[chynasan]

Hello! I mentioned this in our chat, but there are a couple small fixes I wanted to mention that we'd like to see based on a quick review of the Candidate checklist from the original issue posting:

First, the README is missing information about how to install/use this content, as well as the required Python version. The README should also include a link to a copy of the license to make it easier for users to access once the collection is published to AutomationHub. You can see an example of a README from one of our internally-developed collections here if you'd like.

Additionally, there should be a CODEOWNERS file in the repo root outlining at least two maintainers by GitHub username. Since these are mostly documentation-related, I expect they should be pretty easy to fix.