Managing Git Repo Permissions Strategy

[davidcorrigan714]

I'm struggling to understand how to use this provider to effectively manage the entire ACL for a git repo which doesn't seem possible at the moment. For example if I have something like this:

resource "azuredevops_git_repository" "branch-permissions-test" {
  project_id = data.azuredevops_project.my-repo.id
  name       = "permissions-test"
  initialization {
    init_type = "Clean"
  }
}

data "azuredevops_group" "contributors" {
  project_id = data.azuredevops_project.my-repo.id
  name = "Contributors"
}

resource "azuredevops_git_permissions" "contributors-permissions" {
  project_id = data.azuredevops_project.my-repo.id
  repository_id = azuredevops_git_repository.branch-permissions-test.id
  principal  = data.azuredevops_group.contributors.id
  permissions = {
    "Administer" = "NotSet"
    "GenericRead" = "Allow"
    "GenericContribute" = "Allow"
    "ForcePush" = "NotSet"
    "CreateBranch" = "Allow"
    "CreateTag" = "NotSet"
    "ManageNote" = "NotSet"
    "PolicyExempt" = "NotSet"
    "CreateRepository" = "NotSet"
    "DeleteRepository" = "NotSet"
    "RenameRepository" = "NotSet"
    "EditPolicies" = "NotSet"
    "RemoveOthersLocks" = "NotSet"
    "ManagePermissions" = "NotSet"
    "PullRequestContribute" = "Allow"
    "PullRequestBypassPolicy" = "NotSet"
  }
}

Then if I add a user to the repo permissions manually I'd expect terraform to detect that addition and remove the user on the next terraform apply.

[xuzhang3]

Hi @davidcorrigan714 I'm trying understanding your question. Currently your group(Contributors) permission is managed by Terraform, then you add a new user to the group(Contributors), after that when you apply the command terraform apply, you want Terraform remove the new add user and remove associated permissions?

[davidcorrigan714]

@xuzhang3 I was referring to granting a user permissions directly to the repo and not being added to the Contributors group. In the example, I want to enforce that the Contributors group is the only group that has any permissions on the repo, ie it's the one and only access control entry in the access control list for the repo. So if someone set "PullRequestContribute" to Allow for my coworker Caleb directly on the repo that should be detected as a difference and remove them.

Also just realized I botched some of the resource names on the example in my comment, tried to somewhat anonymize things and had a find/replace fail. Here's what I'm actually deploying to our test environment to clear up any mistakes in my example:

resource "azuredevops_git_repository" "branch-permissions-test" {
  project_id = data.azuredevops_project.devcentral.id
  name       = "permissions-test"
  initialization {
    init_type = "Clean"
  }
}

data "azuredevops_group" "contributors" {
  project_id = data.azuredevops_project.devcentral.id
  name = "Contributors"
}

resource "azuredevops_git_permissions" "contributors-permissions" {
  project_id = data.azuredevops_project.devcentral.id
  repository_id = azuredevops_git_repository.branch-permissions-test.id
  principal  = data.azuredevops_group.contributors.id
  replace = true
  permissions = {
    "Administer" = "NotSet"
    "GenericRead" = "NotSet"
    "GenericContribute" = "NotSet"
    "ForcePush" = "NotSet"
    "CreateBranch" = "NotSet"
    "CreateTag" = "NotSet"
    "ManageNote" = "NotSet"
    "PolicyExempt" = "NotSet"
    "CreateRepository" = "NotSet"
    "DeleteRepository" = "NotSet"
    "RenameRepository" = "NotSet"
    "EditPolicies" = "Allow"
    "RemoveOthersLocks" = "NotSet"
    "ManagePermissions" = "NotSet"
    "PullRequestContribute" = "NotSet"
    "PullRequestBypassPolicy" = "NotSet"
  }
}

Bad Caleb, Terraform shouldn't let that permission exist if it's not in the configuration:

[davidcorrigan714]

There also doesn't appear to be a way to control the inheritance option through Terraform as far as I can tell.

[xuzhang3]

ORG permission have high priority, it will override the project level permission configuration.

[davidcorrigan714]

ORG permission have high priority, it will override the project level permission configuration.

Huh?

[davidcorrigan714]

Looks like @tmeckel did the bulk of the work for the permissions resources, any thoughts on this? Happy to do some work to add this type of feature, but want to get some direction on what you all are thinking about it since it'd really be an alternative way to manage permissions as a whole compared to the current strategy which seems to just be able to create & track individual access control list entries.