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.
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
.
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) |
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. |
- 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.
GNU General Public License v3.0 or later
See LICENSE.md to see the full text.
Jakob Meng @jm1 (github, galaxy, web)
Footnotes
-
Useful Ansible modules in this context could be
blockinfile
,copy
,file
,lineinfile
andtemplate
. ↩ -
Tasks will be executed with
jm1.ansible.execute_module
which supports keywordwhen
only. ↩ -
Tasks will be executed with
jm1.ansible.execute_module
which supports modules and action plugins only. Some Ansible modules such asansible.builtin.meta
andansible.builtin.{include,import}_{playbook,role,tasks}
are core features of Ansible, in fact not implemented as modules and thus cannot be called fromjm1.ansible.execute_module
. Doing so causes Ansible to raise errors such asMODULE 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: "" }
. ↩