Uploaded image for project: 'OpenShift Top Level Product Strategy'
  1. OpenShift Top Level Product Strategy
  2. OCPPLAN-7638

Complete Checks & remediations for FedRAMP High controls

    XMLWordPrintable

Details

    • False
    • False
    • Not Set
    • No
    • Not Set
    • Not Set
    • Not Set
    • 100
    • 100% 100%
    • Undefined

    Description

      Out of the controls that have been addressed as part of the High assessment, we can already technically satisfy many items.  This epic covers writing SCAP content and remediations for the controls that can currently be met.  Every single control and remediation that is implemented adds value for the customer, so our approach is to implement as much as possible for the release.  There is no MVP with regards to the number/percentage of goals that need to be implemented.

      There are still functional gaps in OCP related to FedRAMP that have been identified, which are outside of the scope of this epic.  These will be tracked and targeted separately.

      Acceptance Criteria

      • We have the appropriate OpenSCAP checks as defined 
      • We have the appropriate Remediations for checks that can be auto-remediated
      • We have automated testing for the profile

      Documentation Needs

      This epic will be addressed by adding rules to a new "FedRAMP high" SCAP profile that is used by compliance-operator.  SCAP content already includes human-readable guidance documentation that explains all of the rules and remediations that are contained in a profile.  Engineering will be developing this detailed guidance as a part of the profile development.  As such, the documentation needs in our official OpenShift docs for this should be minimal.  Mentioning that additional security content is added to the FedRAMP moderate profile can be covered in the release notes, as the regular documentation should not cover anything in-depth with regards to the rules and remediations inside of a profile.

      The regular documentation needs to mention what profiles we provide, but we currently do not do so. We should add a basic table that lists the provided profiles in the "Understanding the Compliance Operator" chapter. This chapter currently describes how an admin can use the "oc get compliance.profiles" command to list the installed profiles. Providing the table just prior to this command example seems like a good approach. The table should contain the following type of data (all of which can be obtained via "oc get compliance.profiles <profile_name>":

      • Profile name as seen in the API output (ex. - "rhcos4-high")
      • Human-readable profile title (ex. - "NIST 800-53 high-Impact Baseline for Red Hat OpenShift - Platform level")
      • Link to official compliance framework/benchmark/etc. (ex. - "https://csrc.nist.gov/Projects/risk-management/sp800-53-controls/release-search#!/controls?version=5.1&security_baseline=High"

      Note that we should suggest that the admin use the "oc" command example to check what profiles are included in their own deployment. As we ship Compliance Operator updates across all supported OCP releases, new profiles that we develop will be provided for older OpenShift releases. Instead of updating the table of profiles for all old releases, we should instead have a note that the table lists profiles that we provided at the time of release, but they should check their own cluster since new profiles are added over time.
       

      Quality Assurance Needs

      This epic concerns the addition of a large set of rules and remediations to the "high" profile that is used by the compliance-operator. As such, this profile must be tested to ensure the following:

      • The rules are able to get the necessary information
      • The rules generate appropriate remediations
      • The remediations indeed address the found gaps (defines by the rules)
      • The cluster is in a working state after the remediations have been applied

      A proposed test is as follows:

      • In a clean cluster, install the compliance-operator
      • Run a scan for the FedRamp High profile. This will be both a Platform scan and a Node scan which are the ocp4 and rhcos4 profiles respectively.
      • Apply all the suggested remediations
      • Apply manual fixes as suggested by the results (e.g. configure a relevant IdP, use signed images only, etc.)
      • Re-scan
      • Verify that the rules which had issues were fixed and are now in a compliant state
      • Run a smoke test to verify that the cluster is still usable

      References

      The full list of security controls for FedRAMP high are tracked in the OCP NIST SP800-53  kanban board.  This board indicates which controls that we have determined can be met with the current functionality provided by OpenShift Container Platform.

      Attachments

        Issue Links

          Activity

            People

              dcaspin@redhat.com Doron Caspin
              dcaspin@redhat.com Doron Caspin
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: