Add a new directory “modules/security”

[cross-logic]

Proposal: Add a new directory “modules/security”

Author: Massimo Ferrari <@cross-logic>

Date: 2018-04-05

• Status: New
• Proposal type: core design
• Targeted release: Ansible 2.9
• Estimated time to implement: 1 day to 1 week

Motivation

We want to make it easier for users to consume, find and contribute modules interacting with security-specific solutions and services.

Problems

With the increasing adoption of security automation and orchestration practices also grows the number of Ansible modules supporting security solutions. In the absence of a dedicated module category those are spread across multiple categories making their consumption harder and diluting the value of the contributions.

Solution proposal

The creation of new top level module directory lib/ansible/modules/security as a default destination for all modules dedicated to security tools, under development or already submitted. The relocation of all the modules falling in this category to this new directory.

Which modules will belong in modules/security? The “Security” domain encompasses a broad variety of cybersecurity products and services which protect individuals and organizations from the loss or damage to their data, applications, IT systems, networks and devices from malicious or unintended activities. Ansible Security category will be congruent with the industry definition of "logical security." IT Compliance, IT Governance and Physical Security solutions will not be included.

This is a list of the modules that will be relocated: https://docs.google.com/spreadsheets/d/1YWfQ0SqasbIUVx3ETaPctyWr4bjqip4RRMX-bTB4aEk/edit?usp=sharing

Testing (optional)

Unit tests which invoke module code from the Python package name and not the Ansible flattened namespace need to be tested. Any existing unit tests under test/units/modules/ will need to be moved to test/units/modules/security

Documentation (optional)

The current categories are in fact hardly documented at all. Thus there is no need to change documentation.

Anything else?

We are aware that there is also ongoing discussion to move from directory in favor of a more flexible way of content management based on Mazer. However, we are not there yet, and it will take more time and development until that is release ready.

[MarkusTeufelberger]

Your Google document is not public. Please allow public access.

[liquidat]

@MarkusTeufelberger Looks like publicly sharing files is not allowed with our company google apps. This is the list of modules: https://gist.github.com/liquidat/9f81dc1b469dc8e278a2952e5c990ba4

[maxamillion]

For posterity, I wanted to mention in the ticket thread that we should also have a security label in GitHub much like we have for networking, cloud, etc etc so that we can triage, assign groups, and plan accordingly.

[dagwieers]

Currently the directory structure is used for giving people rights on specific collections of code, but also to generate documentation related to collections of modules. If you move some of the e.g. Cisco ASA modules out of network/asa directory structure, people looking for ASA modules will not find some of the modules, or need to be defined in 2 locations in order to maintain these modules.

On the other hand, security goes beyond a firewall or an access list. Managing users on a system relates to security. Managing permissions of files relates to security. Creating a new container relates to security. Authorized keys ? Sudoers ?

So I am not in favor of this. Promoting security and security automation is a noble goal, but touches all technology domains and is a state of mind covering everything you do when automating.

[cross-logic]

@dagwieers thank you for the feedback. The plan is to follow a "per platform" criteria. Which means, as per your example, all Cisco ASA modules will be under security/asa, and the documentation will reflect that accordingly.

Indeed security covers many different areas and practices, but this proposal is not an attempt to being omni comprehensive. As mentioned in the PR, the goal of this change is to promote the organic growth of contributions from security practitioners. The "logical security" domain (which includes all the security applications and platforms that organizations use to provide security management, perimeter defense, intrusion detection and prevention (IDP), access control, authentication, malware protection, encryption, data loss prevention (DLP), etc.) is a convenient starting point, synergetic to other contributions in existing areas (like networking). This doesn't exclude further expansions in a second iteration.

[dagwieers]

I sympathize with that noble goal, but I am not in favor of a generic "security" directory in modules/, as it makes it harder to know where to put a specific module. Cisco ASA is a network security product, there's no doubt it goes into network/ now and that's where people will look for it. If we also have security/ things will be harder to find IMO.

We are better off with an orthogonal classification for the directory structure, and use a more flexible solution for documentation and indexing, which does matter to end-users.

I assume you'd like to see crypto/ and identity/ move to security/ as well ? How about winaudit*, win_certificate_store, win_firewall and win_security_policy ?

[liquidat]

Hey @dagwieers , maybe this is a misunderstanding: with our approach we do want to follow the same way the other directories in the repo are already set up. If you look at the directory dedicated to cloud, the modules in there are focused on platforms’ functionalities. Even if cloud adoption comprises a broader set of topics, including workloads lifecycle and management, user management, networking, and so on. The same is true for storage for example: the modules in that directory focus on platforms even when some functionalities also cover networking and other topics which are strictly speaking not storage.

This is what we want to do for security - and why the “grouping” we want to create is not generic but platform focused. With security, we want to retain the same logic and focus on security technologies/platforms/applications (whose primary goal is providing security capabilities) instead of the general security posture.

[nkakouros]

Isn't this proposal obsolete since collections have been introduced? I also remember a PR that I can't find now that tried to remove the folder hierarchy of modules.

[sivel]

Isn't this proposal obsolete since collections have been introduced

You are correct. I will close this out.