Access control for GitOps
Restrict access to GitOps entities through ABAC
Control access to entities in GitOps through ABAC (Attribute-Based Access Control). ABAC allows fine-grained access to application entities through the use of rules.
For GitOps, you can currently define ABAC for application entities in the Codefresh UI or programmatically via Terraform. For more information on ABAC, see ABAC on Wikipedia.
Rules define the who, what, and where control access to GitOps applications, through the following elements:
Teams control the who part of the rule.
Actions control the what part of the rule. You need to select at least one action.
Attributes control the where part of the rule.
Attributes are a combination of standard Kubernetes and Codefresh-specific attributes. You have Kubernetes attributes such as clusters, namespaces, and labels, and attributes unique to Codefresh such as Runtimes and Git Sources.
Creating a rule in Codefresh UI
For each rule, you must select or define:
- The team or teams the rule applies to, with at least one team being mandatory
- The action or actions permitted for the entity, with at least one action being mandatory
- The attribute or attributes determining where access is permitted
- In the Codefresh UI, on the toolbar, click the Settings icon.
- On the sidebar, from Access & Collaboration, select GitOps Permissions.
- To create a rule, click Add and define the Teams, Actions, and Attributes for the rule.
- To confirm, click Add once again.
The rule you added for the entity is displayed in the GitOps Permissions page. Edit or delete the rule by clicking the respective icons.
Creating a rule programmatically via Terraform
You can also create rules enforcing ABAC for GitOps via Terraform. See the documentation for codefresh_abac_rules.
Argo CD Applications rule elements
|The team or teams to which to give access to the Application Entity. See Adding users and teams.
|The actions permitted for the application entity, and can be any or all of the following:
See Pause/resume ongoing rollouts and Managing an ongoing rollout with the Rollout Player.
|Adding attributes, either individually or in combination, allow more fine-grained access control to enforce the where policies for teams and actions.
Single attributes are useful to grant or deny access based on a specific property. For example, allow access to application entities on a cluster or within a namespace.
Combinations of attributes help enforce more complex access control. For example, require both a Runtime and a Label attribute to grant access to an application entity.
You can also add multiple instances of the same attribute with different values. For example, multiple Label attibutes with different values to sync application entities.
Examples of rules for application entities
Rule: Cluster-based access to all actions
This rule grants the DevOps team permission to perform all actions for application entities on the production cluster, regardless of namespaces, Runtimes, Git Sources and labels.
Rule: Cluster- and namespace-based access to all actions
This rule grants two different teams permissions to perform all actions for application entities deployed on a specific cluster but within a specific namespace.
Rule: Namespace- and label-based access to specific actions
This rule grants the Support team permission to manually sync application entities or manually terminate on-going syncs for application entities deployed in a specific namespace, but only for those entities that share the same label.