README.md

Ansible Role jm1.cloudy.apparmor

This role helps with configuring AppArmor, the Linux kernel security module, from Ansible variables. For example, it allows to enable or edit apparmor.service and edit config files in /etc/apparmor.d/. Variable apparmor_config defines a list of tasks which will be run by this role. Each task calls an Ansible module similar to tasks in roles or playbooks except that only few keywords such as when are supported. For example, to disable apparmor.service define variable apparmor_service_enabled in group_vars or host_vars as false:

apparmor_service_enabled: false

First, this role will install packages for AppArmor which match the distribution specified in variable distribution_id. Next, it will run all tasks listed in apparmor_config. Once all tasks have finished and if anything has changed (and if apparmor_service_state is not set to stopped), then AppArmor's service (set in apparmor_service_name) is restarted to apply changes. When apparmor_service_enabled has been changed, then the system will be rebooted to apply changes.

Tested OS images

• Cloud image (amd64) of Debian 10 (Buster)
• Cloud image (amd64) of Debian 11 (Bullseye)
• Cloud image (amd64) of Debian 12 (Bookworm)
• Cloud image (amd64) of Debian 13 (Trixie)
• Cloud image (amd64) of Ubuntu 18.04 LTS (Bionic Beaver)
• Cloud image (amd64) of Ubuntu 20.04 LTS (Focal Fossa)
• Cloud image (amd64) of Ubuntu 22.04 LTS (Jammy Jellyfish)
• Cloud image (amd64) of Ubuntu 24.04 LTS (Noble Numbat)

Available on Ansible Galaxy in Collection jm1.cloudy.

Requirements

This role uses module(s) from collection jm1.ansible and collection jm1.pkg. To install these collections you may follow the steps described in README.md using the provided requirements.yml.

Variables

Name	Default value	Required	Description
apparmor_config	[]	false	List of tasks to run 1 2 3, e.g. to configure files in /etc/apparmor.d/
apparmor_service_enabled	true	false	Whether the AppArmor service should start on boot
apparmor_service_name	apparmor	false	Name of the AppArmor service
apparmor_service_state	started	false	State of the AppArmor service
distribution_id	depends on operating system	false	List which uniquely identifies a distribution release, e.g. [ 'Debian', '10' ] for Debian 10 (Buster)

Dependencies

Name	Description
jm1.pkg.setup	Installs necessary software for module jm1.pkg.meta_pkg from collection jm1.pkg. This role is called automatically, manual execution is NOT required.

Example Playbook

- hosts: all
  become: true
  roles:
  - name: Manage AppArmor service
    role: jm1.cloudy.apparmor
    tags: ["jm1.cloudy.apparmor"]

For a complete example on how to use this role, refer to host lvrt-lcl-session-srv-034-ubuntu2204 from the provided examples inventory. The top-level README.md describes how this host can be provisioned with playbook playbooks/site.yml.

For instructions on how to run Ansible playbooks have look at Ansible's Getting Started Guide.

License

GNU General Public License v3.0 or later

See LICENSE.md to see the full text.

Author

Jakob Meng @jm1 (github, galaxy, web)

Footnotes

1. Useful Ansible modules in this context could be blockinfile, copy, file, lineinfile and template. ↩

2. Tasks will be executed with jm1.ansible.execute_module which supports keyword when only. ↩

3. Tasks will be executed with jm1.ansible.execute_module which supports modules and action plugins only. Some Ansible modules such as ansible.builtin.meta and ansible.builtin.{include,import}_{playbook,role,tasks} are core features of Ansible, in fact not implemented as modules and thus cannot be called from jm1.ansible.execute_module. Doing so causes Ansible to raise errors such as MODULE FAILURE\nSee stdout/stderr for the exact error. In addition, Ansible does not support free-form parameters for arbitrary modules, so for example, change from - debug: msg="" to - debug: { msg: "" }. ↩