open-gitops
Access Control
By doing GitOps access control moves from Kubernetes to git. Controllers which apply git resources to a cluster such as GitOps Engine might provide mechanisms to control which kinds of resources might be applied or in which namespaces those might be created.
Managing larger clusters, which contain applications from multiple teams moves permission management from pure RBAC within the cluster to git. It suddenly becomes important to which repositories people have access to, where they can make changes and who needs to approve what.
Repository features, which allow you to control who needs to review which directory are helpful, but not the only thing to consider.
Documentation around repository best practices explaining pros and cons of different setups might guide users to decide based on their needs.
Some options worth describing:
- one repo per cluster
- one cluster repo + one/multiple application repositories
- different stages within one repo vs staged in branches vs different repos per stage
@torstenwalter this would make a good best practices doc. There is some movement on repo structure again recently. Would you like to participate in this again? Could definitely use your input 💯 https://github.com/open-gitops/documents/pull/51
Given #51 has been closed I'd love to revive the discussion here as I am more and more certain this might be a crucial change of mindset when you can't possibly rely on K8s' RBAC functionality to manage access control but have to resort to what's possible with git.
RBAC has many benefits and people quickly feel they'd be losing something when switching to git. Much of what's possible will probably be dependant on the git server implementation (SSO features etc.) but IMHO guidance needs to be provided on how to map K8s RBAC functionality to a git-centric model.
@scottrigby @torstenwalter wdyt?
I still believe that this is useful. Although I don't have the time to work on this.