Epic Goal

• Have a more complete policy out of the box by guessing the read/write rules based on container mounts

Why is this important?

• The policies should be as complete as possible and require as little post-recording intervention as possible

Scenarios

1. 
   Idea: if it's possible for security-profiles-operator to get describe information about a pod, it could create an initial set of allow rules based on volumes mounted. E.g. if a containers mounts /var/www/html with httpd_sys_content_t SELinux type, we can expect that the container will read directories and files with this type and therefore rules allowing these could be added automatically.

This is a follow up of https://issues.redhat.com/browse/CMP-1316

Acceptance Criteria

• record a pod that mounts a volume read-only, verify the policy allows to read that type
• record a pod that mounts a volume read-write, verify the policy allows to read and write that type

Dependencies (internal and external)

1. N/A

Previous Work (Optional):

1. Udica does something similar

Open questions::

1. …

Done Checklist

• CI - CI is running, tests are automated and merged.
• Release Enablement <link to Feature Enablement Presentation>
• DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
• DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
• DEV - Downstream build attached to advisory: <link to errata>
• QE - Test plans in Polarion: <link or reference to Polarion>
• QE - Automated tests merged: <link or reference to automated tests>
• DOC - Downstream documentation merged: <link to meaningful PR>