Getting started
Using debops.apparmor from other roles
One common use case for debops.apparmor
is to use it from other roles
to perform customizations to the AppArmor profiles shipped with various
packages and stored under the /etc/apparmor.d/
directory.
To do this, you can define the desired AppArmor modifications in your
defaults/main.yml
file. For example:
# Configuration for the ``debops.apparmor`` role, customizing the system
# profile for slapd to work in a DebOps environment.
slapd__apparmor__dependent_locals:
- name: 'usr.sbin.slapd'
options:
- name: '/etc/pki/**'
value: 'r'
comment: 'Allow slapd access to DebOps PKI data'
And then in the playbook for this role, pass the
slapd__apparmor__dependent_locals
variable over to the debops.apparmor
role:
---
- name: Manage OpenLDAP service
...
hosts: [ 'debops_service_slapd']
...
roles:
- role: debops.apparmor
tags: [ 'role::apparmor', 'skip::apparmor' ]
apparmor__dependent_locals:
- '{{ slapd__apparmor__dependent_locals }}'
There are three different variables which can be used to perform customizations
of the local AppArmor configuration via role dependencies
(apparmor__dependent_profiles
, apparmor__dependent_locals
and apparmor__dependent_tunables
), see apparmor__profiles,
apparmor__locals and apparmor__tunables for more details,
including the syntax of each variable.
Containers
Warning
Note that AppArmor will not necessarily work properly inside containers and may cause issues with applications running in a containerized environment.
As an example, if you setup a systemd-nspawn(1) container/guest and AppArmor is enabled on the host system, the AppArmor profiles from the host will be enforced inside the container, even though they are not configured inside the container and tools such as aa-enabled will, if executed inside the container, report that AppArmor is not enabled.
Any changes to an AppArmor profile that interferes with the proper running of a given service would therefore have to be performed on the host, rather than the container/guest.
Your mileage might vary depending on the container technology used and its level (and maturity) of support for AppArmor.
Example inventory
debops.apparmor
is included by default in the common.yml
DebOps
playbook; you don't need to do anything to have it executed.
Example playbook
If you are using this role without DebOps, here's an example Ansible playbook
that uses the debops.apparmor
role:
---
# SPDX-License-Identifier: GPL-3.0-or-later
- name: Install and configure AppArmor
collections: [ 'debops.debops', 'debops.roles01',
'debops.roles02', 'debops.roles03' ]
hosts: [ 'debops_all_hosts', 'debops_service_apparmor' ]
become: True
environment: '{{ inventory__environment | d({})
| combine(inventory__group_environment | d({}))
| combine(inventory__host_environment | d({})) }}'
roles:
- role: apparmor
tags: [ 'role::apparmor', 'skip::apparmor' ]
Other resources
List of other useful resources related to the debops.apparmor
Ansible role:
Manual pages: apparmor(7), apparmor.d(5) and the manpages for the various
aa-*
utilities (like aa-status(8), aa-enabled(1), aa-disable(8), aa-complain(8) and aa-enforce(8))The website of the AppArmor Project
The Ubuntu Wiki Page
The Debian Wiki Page, including the HowToUse subpage