chore: eject repo policy compliance

.github/workflows/integration_test.yaml

@@ -20,7 +20,7 @@ jobs:
       juju-channel: 3.6/stable
       provider: lxd
       test-tox-env: integration-juju3.6
-      modules: '["test_charm_metrics_failure", "test_charm_metrics_success", "test_charm_fork_repo", "test_charm_fork_path_change", "test_charm_no_runner", "test_charm_runner", "test_debug_ssh", "test_charm_upgrade",  "test_reactive"]'
+      modules: '["test_charm_metrics_failure", "test_charm_metrics_success", "test_charm_fork_path_change", "test_charm_no_runner", "test_charm_runner", "test_debug_ssh", "test_charm_upgrade",  "test_reactive"]'
       # INTEGRATION_TOKEN, INTEGRATION_TOKEN_ALT, OS_* are passed through INTEGRATION_TEST_SECRET_ENV_VALUE_<N>
       # mapping. See CONTRIBUTING.md for more details.
       extra-arguments: |

config.yaml

@@ -85,13 +85,6 @@ options:
       Minutes between each reconciliation of the current runners state and their targeted state.
       On reconciliation, the charm polls the state of runners and see if actions are needed. The
       value should be kept low, unless Github API rate limiting is encountered.
-  repo-policy-compliance-token:
-    type: string
-    description: >-
-      DEPRECATED, please use allow-external-contributor configuration option instead.
-      The token to authenticate with the repository-policy-compliance service in order to
-      generate one-time-tokens. This option requires the repo-policy-compliance-url to be set.
-      If not set, the repository-policy-compliance service will not be used.
   repo-policy-compliance-url:
     type: string
     description: >-

docs/changelog.md

@@ -2,13 +2,17 @@
 
 This changelog documents user-relevant changes to the GitHub runner charm.
 
+## 2025-12-09
+
+- Deprecate `repo-policy-compliance` service.
+
 ## 2025-12-05
 
 - Modified pre-job script to distinguish between internal PRs and fork PRs when applying author association checks. Internal PRs (where head and base repositories match) now skip the author association check, allowing team members to run workflows on their internal branches. Fork PRs continue to enforce OWNER/MEMBER/COLLABORATOR requirements for security.
 
 ## 2025-12-01
 
-- Added timeouts to API calls (Openstack,GitHub,Repo policy compliance) to fix a hanging GitHub runner manager application. 
+- Added timeouts to API calls (Openstack,GitHub,Repo policy compliance) to fix a hanging GitHub runner manager application.
 
 ## 2025-11-30
 
@@ -39,7 +43,6 @@
 
 - Fix issue with scaling down overshooting in deleting runners after cleanup
 
-
 ## 2025-08-20
 
 - Document relevant log files.
@@ -72,7 +75,7 @@
 ## 2025-07-09
 
 - Specify max supported nova compute API to be 2.91. This fixes an issue where the charm could fail
- due to a bug on the OpenStack side: https://bugs.launchpad.net/nova/+bug/2095364
+  due to a bug on the OpenStack side: https://bugs.launchpad.net/nova/+bug/2095364
 
 ### 2025-06-30
 
@@ -92,8 +95,7 @@
 ### 2025-06-16
 
 - Revert `copytruncate logrotate` method for reactive processes, as `copytruncate` keeps log files on disks and does not remove them, and each process is writing to a new file leading to a huge and increasing amount
-of zero sized files in the reactive log directory. This is a temporary fix until a better solution is implemented, as it has the downside that long lived reactive processes may write to deleted log files.
-
+  of zero sized files in the reactive log directory. This is a temporary fix until a better solution is implemented, as it has the downside that long lived reactive processes may write to deleted log files.
 
 ### 2025-06-12
 
@@ -105,9 +107,9 @@
 
 ### 2025-06-04
 
-- Reduce the reconcile-interval configuration from 10 minutes to 5 minutes. This is the interval 
-between reconciling the current and intended number of runners. The value should be kept low, 
-unless GitHub API rate limiting is encountered.
+- Reduce the reconcile-interval configuration from 10 minutes to 5 minutes. This is the interval
+  between reconciling the current and intended number of runners. The value should be kept low,
+  unless GitHub API rate limiting is encountered.
 - Removed the reconcile-runners Juju action.
 
 ### 2025-06-03
@@ -116,9 +118,8 @@
 
 ### 2025-05-22
 
-- Add possibility to run a script in the pre-job phase of a runner. This can be useful to setup 
-network/infrastructure specific things.
-
+- Add possibility to run a script in the pre-job phase of a runner. This can be useful to setup
+  network/infrastructure specific things.
 
 ### 2025-05-09
 
@@ -127,8 +128,8 @@
 ### 2025-05-06
 
 - The ssh health checks are removed and GitHub is used instead to get the runners health
-information. This implies many changes in both the structure of the project and its functionality. Potentially, many race conditions should
-disappear.
+  information. This implies many changes in both the structure of the project and its functionality. Potentially, many race conditions should
+  disappear.
 
 ### 2025-04-28
 
@@ -162,7 +163,7 @@
 ### 2025-03-24
 
 - New terraform product module. This module is composed of one github-runner-image-builder application and the related
-github-runner applications.
+  github-runner applications.
 
 ### 2024-12-13
 
@@ -208,14 +209,14 @@
 ### 2024-10-17
 
 - Use in-memory authentication instead of clouds.yaml on disk for OpenStack. This prevents
-the multi-processing fighting over the file handle for the clouds.yaml file in the `github-runner-manager`.
+  the multi-processing fighting over the file handle for the clouds.yaml file in the `github-runner-manager`.
 
 - Fixed a bug where metrics storage for unmatched runners could not get cleaned up.
 
 ### 2024-10-11
 
 - Added support for COS integration with reactive runners.
-- The charm now creates a dedicated user which is used for running the reactive process and 
+- The charm now creates a dedicated user which is used for running the reactive process and
   storing metrics and ssh keys (also for non-reactive mode).
 
 ### 2024-10-07

docs/explanation/charm-architecture.md

@@ -8,7 +8,6 @@ Conceptually, the charm can be divided into the following:
 - Management of the virtual machine image
 - Management of the network
 - GitHub API usage
-- Management of [Python web service for checking GitHub repository settings](https://github.com/canonical/repo-policy-compliance)
 - Management of dependencies
 
 # Description of the charm's main components
@@ -112,18 +111,28 @@ The charm requires a GitHub personal access token for the [`token` configuration
 - Requesting a list of self-hosted runners configured in an organization or repository
 - Deleting self-hosted runners
 
-The token is also passed to [repo-policy-compliance](https://github.com/canonical/repo-policy-compliance) to access GitHub API for the service.
-
 Note that the GitHub API uses a [rate-limiting mechanism](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28). When this is reached, the charm may not be able to perform the necessary operations and may go into
 BlockedStatus. The charm will automatically recover from this state once the rate limit is reset, but using a different token with a higher rate limit may be a better solution depending on your deployment requirements.
 
 <!-- vale Canonical.007-Headings-sentence-case = NO -->
-## GitHub repository setting check
+## External contributor access control
 <!-- vale Canonical.007-Headings-sentence-case = YES -->
 
-The [repo-policy-compliance](https://github.com/canonical/repo-policy-compliance) is a [Flask application](https://flask.palletsprojects.com/) hosted on [Gunicorn](https://gunicorn.org/) that provides a RESTful HTTP API to check the settings of GitHub repositories. This ensures the GitHub repository settings do not allow the execution of code not reviewed by maintainers on the self-hosted runners.
-
-Using the [pre-job script](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/running-scripts-before-or-after-a-job#about-pre--and-post-job-scripts), the self-hosted runners call the Python web service to check if the GitHub repository settings for the job are compliant. If not compliant, it will output an error message and force stop the runner to prevent code from being executed.
+The charm provides security controls for managing external contributor access through the `allow-external-contributor` configuration option.
+External contributors are defined as users not in COLLABORATOR, MEMBER, or OWNER status. For
+example, pull requests from fork repositories from users not in COLLABORATOR, MEMBER or OWNER
+status would be considered requests from an external contributor. Internal requests such as
+an internal PR from a renovate bot account would not be considered an event from an external
+contributor.
+When set to `false`, the charm restricts workflow execution to external contributors for the following GitHub events:
+
+- `pull_request` - Pull requests from external contributors
+- `pull_request_target` - Pull request targeting (designed for handling PRs from forks)
+- `pull_request_review` - Pull request reviews from external contributors  
+- `pull_request_review_comment` - Comments on pull request diffs from external contributors
+- `issue_comment` - Comments on issues or pull requests from external contributors
+
+Using the [pre-job script](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/running-scripts-before-or-after-a-job#about-pre--and-post-job-scripts), the self-hosted runners check the author association of the user triggering the workflow. If the user does not have sufficient permissions, the runner will output an error message and stop execution to prevent unauthorized code from running.
 
 ## COS integration
 Upon integration through the `cos-agent`, the charm initiates the logging of specific metric events

docs/explanation/security.md

@@ -6,12 +6,13 @@
 
 The charm manages GitHub self-hosted runners to run GitHub Actions jobs. This allows users on GitHub to execute code on the servers hosting the runners, which poses a remote code execution risk if the code is not trusted. Therefore, the charm should only spawn runners to trusted organizations or repositories.
 
-For third-party contributions, the charm can integrate with the [Repo Policy Compliance charm](https://charmhub.io/repo-policy-compliance) to manage the repository policy. With this integration, the self-hosted runner will not execute the GitHub jobs if the policy is not met. See [working with outside collaborators](https://charmhub.io/github-runner/docs/how-to-comply-security#working-with-outside-collaborators) for the recommended settings to ensure the code is reviewed by a trusted user prior to execution in the runner.
+For external contributor security, see [How to manage external contributors securely](../how-to/manage-external-contributors.md) for configuration options and recommended practices.
 
 ### Good practices
 
 - Only register the GitHub self-hosted runners to a trusted organization or repository so that only workflows from trusted users are able to run on the runners.
-- For outside collaborators: Use the [`repo-policy-compliance` charm](https://charmhub.io/repo-policy-compliance) with [policy for outside collaborators](https://charmhub.io/github-runner/docs/how-to-comply-security#working-with-outside-collaborators) to ensure the code executed in runners are reviewed by a trusted user.
+- For outside collaborators: Use the `allow-external-contributor` configuration option (set to `false`) to restrict workflow execution to users with COLLABORATOR, MEMBER, or OWNER status. This prevents unauthorized code execution from untrusted external contributors.
+- Configure appropriate repository settings and protection rules to ensure the code executed in runners are reviewed by a trusted user.
 
 ## Permission for GitHub app or personal access token
 

docs/how-to/comply-security.md

@@ -2,9 +2,29 @@
 
 According to GitHub, running code inside the GitHub self-hosted runner [poses a significant security risk of arbitrary code execution](https://docs.github.com/en/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners#self-hosted-runner-security). The self-hosted runners managed by the charm are isolated in its own single-use virtual machine instance. In addition, the charm enforces some repository settings to ensure all code running on the self-hosted runners is reviewed by someone trusted.
 
-The charm can be integrated with the [Repo Policy Compliance charm](https://charmhub.io/repo-policy-compliance) to enforce a set of good practices around GitHub repository settings. Self-hosted runners managed by the charm will not run jobs on repositories unless they are compliant with the practices.
+The charm provides the `allow-external-contributor` configuration option to control whether workflows triggered by external contributors can execute on the self-hosted runners. When set to `false`, only users with COLLABORATOR, MEMBER, or OWNER status can trigger workflows from pull requests, reviews, and comments.
 
-In this guide, a recommended set of policies will be presented.
+In this guide, a recommended set of policies and security practices will be presented.
+
+## External contributor access control
+
+Configure the charm to restrict external contributor access:
+
+```bash
+juju config github-runner allow-external-contributor=false
+```
+
+With this setting, workflows will only run for users with the following GitHub author associations:
+- `OWNER` - Repository or organization owners
+- `MEMBER` - Organization members  
+- `COLLABORATOR` - Users with explicit collaborator access
+
+The charm checks author associations for these events:
+- `pull_request` - Pull requests from external contributors
+- `pull_request_target` - Pull request targeting (designed for handling PRs from forks)
+- `pull_request_review` - Pull request reviews from external contributors
+- `pull_request_review_comment` - Comments on pull request diffs from external contributors
+- `issue_comment` - Comments on issues or pull requests from external contributors
 
 ## Recommended policy
 
@@ -20,4 +40,12 @@
 
 ### Working with outside collaborators
 
-Generally, outside collaborators are not completely trusted, but still would need to contribute in some manner. As such, this charm requires pull requests by outside collaborators to be reviewed by someone with `write` permission or above. Once the review is completed, the reviewer should add a comment including the following string: `/canonical/self-hosted-runners/run-workflows <commit SHA>`, where `<commit SHA>` is the commit SHA of the approved commit. Once posted, the self-hosted runners will run the workflow for this commit.
+When `allow-external-contributor` is set to `false`, outside collaborators can still contribute through the following secure workflow:
+
+1. External contributors create pull requests as usual
+2. A repository maintainer with COLLABORATOR, MEMBER, or OWNER status reviews the code
+3. If the code is safe, the maintainer can:
+  - Approve and merge the pull request to another branch (workflows will run with the maintainer's permissions)
+  - Manually trigger workflow runs if needed (using workflow dispatch on the target branch)
+
+This approach ensures that all code from external contributors is reviewed by trusted users before execution on self-hosted runners, eliminating the need for manual comment-based approval workflows.