• Icon: Epic Epic
    • Resolution: Won't Do
    • Icon: Undefined Undefined
    • None
    • None
    • None
    • SPO: Incremental recording of policies
    • False
    • None
    • False
    • Not Selected
    • To Do
    • 0
    • 0% 0%

      Epic Goal

      • SPO would allow administrators to iterate on their recorded policies

      Why is this important?

      • Typically the first version of a policy will be recorded in CI, capturing all CI runs. No matter how extensive the CI runs, there will still be issues that won't be caught in the policy. Therefore it is important to provide means for the admin to adjust the policy, the more automatic, the better.

      Scenarios

      1. a first version of a policy is recorded, probably using CI runs
      2. it is assumed that this version will not catch all uses of the software and therefore denials would happen in production
      3. these denials should be merged

      Acceptance Criteria

      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      Dependencies (internal and external)

        • Run a policy either in permissive or in enforcing mode, watch for AVCs with this policy, either merge automatically (easier, but less secure) or create a follow-up policy
        • Make sure to not reload on every AVC to not flood the nodes with node reloads, on the other hand, don’t just keep the AVCs in memory or else the partial policy will prevent the app from working
        • One option is to have separate filed under a directory, but policy handling would be a PITA
        • Policy reloading should work OOTB

      Previous Work (Optional):

      1. The policy merging in CMP-1144

      Open questions::

      1. see above, we'd need to figure out the balance between auto-merging the new policies (dangerous) or letting the admin know that there's a new policy and provide means to merge manually.

      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>

            Unassigned Unassigned
            jhrozek@redhat.com Jakub Hrozek
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: