READING organization repository rulesets should not require WRITE permissions

[lukas-hetzenecker]

Select Topic Area

Product Feedback

Body

Hello,

we're provisioning our Github settings via Infrastructure as Code.

And when doing that, we always implement least privileges for that - generally speaking, this means when terraform applies our settings, tokens with WRITE permissions will be used. When generating plans, usually only GET calls are made, and therefore READ permissions on the various permissions should be sufficient.

Recently we tried to use the github_organization_ruleset resource:

resource "github_organization_ruleset" "example" {
  name        = "example"
  target      = "branch"
  enforcement = "active"

  conditions {
    ref_name {
      include = ["~ALL"]
      exclude = []
    }
  }

  bypass_actors {
    actor_id    = 13473
    actor_type  = "Integration"
    bypass_mode = "always"
  }

  rules {
    creation                = true
    update                  = true
    deletion                = true
    required_linear_history = true
    required_signatures     = true

    branch_name_pattern {
      name     = "example"
      negate   = false
      operator = "starts_with"
      pattern  = "ex"
    }
  }
}

Unfortunately this breaks our security model, as we noticed that our token permissions are not sufficient for organization rulesets.

In particular, when running a terraform plan, the following API endpoint will be used:

GET /orgs/{org}/rulesets

According to the Permissions description, this endpoint requires
organization_administration: WRITE permissions.

This strikes us a bit odd - why is this GET endpoint requiring WRITE permissions, when it is only reading all organization repository rulesets?
For other read requests in this category, READ permissions are sufficient.

This breaks our IaC workflows, and we therefore cannot make use of Rulesets in our organization.

[ghostinhershell]

Hey there @lukas-hetzenecker,

Thanks so much for reaching out in our community. This issue was recently raised with our support team and this was the final verdict:

Our engineering team have investigated and stated that the behaviour is currently working as designed. We've submitted a customer feedback request to make this capability "read-only". We can't say when or if it will be released but we'd recommend that you keep an eye on the Changelog where updates are announced.

A feature request was opened for this endpoint to be added. I've added this Discussion to that feature request to show that there is demand for reducing permissions where appropriate.

In the meantime, please feel free to follow-up here and let me know if you have any additional questions.

[tgrnwd]

I have the same exact use case as described in the original post, and am similarly disappointed to discover this GET endpoint:

• GET /orgs/{org}/rulesets

requires elevated WRITE permissions.

We manage org-wide SCM policy thru terraform in an "internal" repo, and the entire org is encouraged to submit pull requests to continuously improve our policy and process. We want to use org rulesets, but all members of the org (who already have write access to our policy management repo) would then receive access to an Org Admin Write app token. This is not desirable. I want to use a read only app token for workflows that run in a pull request, and keep my write token behind an environment approval to use when changes are approved.

Are there any updates on the feature request?

[t2farrell]

I agree with the original poster, although our use case is different. We work with a security and compliance partner who conducts a variety of automated testing on our infrastructure, including github (e.g. ensuring that branch protection rules are enabled on repositories). However, this required write permission access to make a READ request means that in order to test our rulesets, they need this permission, which it appears at the same time would also grant the partner permission to delete our entire github organization? That does not support the principle of least privilege and makes no sense to me.

[danielzev]

Hi @ghostinhershell. @danielzev here... Co-Founder & CTO of one of those security and compliance partners @drata that @t2farrell mentioned above.

I 100% agree with all of the posters on this thread, that this seems wrong. I would love to understand how the behavior is currently working as designed came to be. We're all making GET calls to the ruleset APIs (specifically these two):

GET /orgs/{org}/rulesets

GET /orgs/{org}/rulesets/{ruleset_id}

Those should be under a READ ONLY permission. It would make sense if the GET API endpoints were allowed under the Organization permissions: Administration permission with a Read-only scope.

I would be more than happy to connect here, on email, phone, or a Zoom call to talk through it. We have 1000's of mutual customers with you that are not happy with the Read and write decision that was made.

[paulsavoie]

Hi @ghostinhershell,

we have the exact same issue at SignPath. We evaluate ruleset rules for our customers and they (rightfully) ask why our App would need write permissions on their organizations, which can do so much more and potentically cause a lot of damage.

I think that the detailed permission model in GitHub is great and that we can scope our app to really only have the permissions it needs, but for ruleset rules this is just not the case. Please change it or at least elaborate as to why the decision was taken.