[larsks]

Add workflows that will automatically apply this configuration to the CCI-MOC github organization when changes merge to the main branch.

[msdisme]

Trying to approach this from a compliance perspective:

1. How are changes to the various CSVs managed and protected? If I'm reading it right, the new workflows only run when the Terraform files change, so I wasn't sure how CSV changes get applied and logged. (3.4.3)

2. How long are the Actions logs kept, and do they need to be longer for 800-171 and HIPAA? I believe GitHub caps it at 90 days for a public repo like this one. @knikolla may know offhand. (3.3.1, 3.4.3)

3. Since a merge to main seems to change the org right away, should there be more controls over who can make changes, such as a required review before merge? Today that's the ops-core team. Is that meant to be the everyday path, or closer to a break-glass capability? And is the intent that this list will change as we approach production? (3.4.5)

4. Will different environments (Open Science vs. HIPAA, for example) have different sets of approvers?

[larsks]

How are changes to the various CSVs managed and protected? If I'm reading it right, the new workflows only run when the Terraform files change, so I wasn't sure how CSV changes get applied and logged. (3.4.3)

Despite your protestations to the contrary, you are an excellent reviewer! That was a good finding and was an error on my part; I have updated the workflows to trigger on changes to the csv files as well.

How long are the Actions logs kept, and do they need to be longer for 800-171 and HIPAA? I believe GitHub caps it at 90 days for a public repo like this one. @knikolla may know offhand. (3.3.1, 3.4.3)

The answer depends on what you're looking for:

• Information about who authored a change is preserved in the git history. That is preserved indefinitely as part of the repository, barring someone editing history (which we can prevent through appropriate github rulesets).

• Information about who approved a change is preserved in the pull request, which exists for the lifetime of the repository.

• Information about who approved a change is also available in the organization audit logs for 180 days.

Since a merge to main seems to change the org right away, should there be more controls over who can make changes, such as a required review before merge? Today that's the ops-core team. Is that meant to be the everyday path, or closer to a break-glass capability? And is the intent that this list will change as we approach production? (3.4.5)

Once this merges, the immediately proximate pull request will be one that adds a branch protection ruleset to this repository requiring two approving reviews before a change can merge. I'm sure this list of approvers will change as we move forward.

Will different environments (Open Science vs. HIPAA, for example) have different sets of approvers?

If they do, we can address that through path-based protection rules in GitHub. This may require some restructuring of the repository (so that different classes of repository are managed in different paths).