GitHub Permissions Mitigations
Last updated
Last updated
Arnica mitigates excessive permissions based on observed activities within each branch in each repository. This page describes the expected changes from each of the mitigation options.
Arnica creates a Pull Request with the modified CODEOWNERS file based on the Pull Request activities in each of the branches. If there have been no recent Pull Requests (based on the policy configurations), there is insufficient context to create a CODEOWNERS file.
By selecting this mitigation option, Arnica will generate a CODEOWNERS file and create a Pull Request to approve these changes. Upon approval, Arnica will enable the branch protection policies to require at least 1 approver from the Code Owners file is enabled, as in the screenshot below:
Arnica creates a Pull Request with the modified CODEOWNERS based on the Pull Request activities in each of the branches.
Instead of removing members from Teams, adjusts the CODEOWNERS file by removing the original Team slugs (e.g. @org_name/team_slug) that have members with excessive permissions and replacing them with Arnica-managed Teams with the naming convention "@org_name/[arnica]-{repo}-{branch}-{path]-CODEOWNERS".
For example, the screenshot below demonstrates the changes between a manually configured CODEOWNERS file and the Arnica-managed Teams:
To ensure that CODEOWNERS are the only ones who can approve Pull Requests before merging, Arnica will ensure that the branch protection policies require at least 1 approver from the CODEOWNERS file is enabled, as in the screenshot in the "Create and enforce CODEOWNERS" above.
When a repository does not have any branches with recently merged code from Pull Requests, Arnica will assess which branches need to be protected by restricting who can push to these branches. By selecting this mitigation option, Arnica will enable the branch protection policy for each of the selected branches. Below is a screenshot of the anticipated result when only a single user needs to push code to a given branch.
Maintainer excessive permissions are analyzed by observing the activities in the audit trail that are associated to this role.
If the Maintain permission is direct between the user and the repository, the permission will be reduced to Write. However, if the permission is granted through a Team, all members with recent maintenance activity will be granted with a direct Maintain permission, and then the Team permission will be reduced to have Write access.
If a new member is added to the Team on GitHub, Arnica will automatically provision the Maintain permission for this member and exclude the excessive permissions identification for the minimum time defined in Arnica's policy. You can change the default minimum time to match your company's policies.
Arnica handles it similarly with nested Teams.
Repository Admin permissions are analyzed by observing the activities in the audit trail that are associated to this each of these roles.
If the Repository Admin permission is direct between the user and the repository, the permission will be reduced to Maintain, only if the user performed maintenance activities recently. If the user has excessive Maintain permissions as well, the permission will be reduced to Write.
If the permission is granted through a Team, all members with recent maintenance activity will be granted with a direct Maintain permission, if they performed maintenance activities recently. The permission of this Team will be reduced to have a Write access.
If a new member is added to the Team on GitHub, Arnica will automatically provision the Repository Admin permission for this member and exclude the excessive permissions identification for the minimum time defined in Arnica's policy. You can change the default minimum time to match your company's policies.
Arnica handles it similarly with nested Teams.
Why does Arnica not reduce permissions to Triage or read?
By applying the branch protection policies above, the effective permission of the users outside of the branch protection will be restricted to either push directly to the important branch or to approve Pull Requests before merging code into the protected branch.
Can I revert any of the mitigations?
Yes. Arnica takes a snapshot of the permissions and branch protection state before the change and allows to revert the action exactly in the opposite order it was executed, e.g. Arnica will create a Pull Request with a past CODEOWNERS file upon selecting a revet on Modify CODEOWNERS action.
How can permissions be granted?
Arnica listens to team membership addition events and adds users to specific Maintain or Admin permission, if the permission of the Team was mitigated from Maintain or Admin down to Write.
To simplify the permissions management process, Arnica supports self-service approval and provisioning process, as defined in Arnica's policy. For example, specific permission levels (admin vs. contributor) to specific repositories can be granted automatically via a single Slack message, and other permissions to other repositories can automatically be granted via Slack upon approval in a pre-defined private channel.
Can I exclude users from excessive permissions assessment?
Yes. Any user, Team, and Repository can be excluded from permissions reduction. When an excessive permission is mitigated, the excluded users and Teams will be automatically granted with the permission to the asset.
