Access control

How to restrict resources in a company environment

Codefresh provides two complementary ways for access control within an organization. Both of them depend on the existence of users and teams with proper access level.

The first mechanism is a way to restrict access to parts of the UI that are intended for account administrators. For example, only an account administrator should be able to change integrations with git providers and cloud services.

The second mechanism is policy-based access control via attributes (ABAC) on Kubernetes clusters and pipelines. This allows account administrators to define exactly which teams have access to which clusters and pipelines. For example, access to production clusters should only be granted to a subset of trusted developers/operators. On the other hand, access to a QA/staging cluster can be less strict.

There is also the additional layer of permissions for resources (such as concurrent builds and environments) as explained in the Enterprise Account Management page.

Users and administrators

You can define the level of access (user or administrator) from the same screen where you add collaborators to your account. From the left sidebar of the Codefresh UI choose Account Settings and then click on the People menu item under User Management.

User access control

User access control

Next to each user you can click the drop-down box to decide the level access. There is another drop-down for the SSO configuration as well.

Note that you need to be an administrator yourself, in order to add new users and change their roles.

People with User access level can still use the Codefresh UI for day-to-day operations such as running pipelines, looking at Docker images and inspecting test reports but they don’t have access to following screens:

Only people with Administrator level have access to the respective UI screens.

Note however that Users can still control their own email notification settings.

Access to Kubernetes clusters and Pipelines

Codefresh also provides fine-grained control to Kubernetes clusters and pipelines via attributes (ABAC). The process involves 3 steps:

  1. Assigning custom attributes to your Kubernetes clusters and/or pipelines
  2. Creating teams and assigning users to them
  3. Defining policies using teams, clusters and attribute (who, what, where)

Let’s see these steps in order.

Marking Kubernetes clusters with policy attributes

You can mark your clusters in the Cloud provider integration page.

Cluster tags

Cluster tags

To add a new tag/attribute, hover your mouse on a cluster and click on the Edit tags button on the right. You will get a new dialog where you can add multiple tags on a single cluster.

Assigning attributes to a cluster

Assigning attributes to a cluster

The tag names are arbitrary and can be anything you choose that matches your company process. You can mark your clusters with product names, software lifecycle phases, department names or anything that helps your security policies. Note that each cluster can be assigned multiple tags, so it very easy to define multiple policies on the same cluster (e.g per project and per team).

Notice that by default, all untagged clusters are seen and can be edited by all users (but not deleted). As soon as you add at least one tag on a cluster, this cluster will only be accessible to people that match the affected policy rules (explained in the next sections).

Marking pipelines with policy attributes

You can also mark specific pipelines with tags. To do this click on the Configure menu on a pipeline and select edit tags

Assigning attributes to a pipeline

Assigning attributes to a pipeline

Tagging pipelines works in a similar manner to Kubernetes clusters.

Once your clusters and pipelines are tagged, you should create teams that work on these clusters.

Creating teams

To create and manage teams of people, from the left sidebar of the Codefresh UI choose Account Settings and then click on the Team menu item under User Management.

Only Enterprise customers can add new teams. Other Codefresh plans can only use the predefined Users and Admin teams. Contact us if you wish to upgrade to an Enterprise plan.

Note that team names should only contain lower case alphanumeric characters and hyphens. Spaces are not allowed. See the screenshot below for some sample team names.

Managing teams

Example teams in Codefresh

On this screen you can:

  • Create a new team by clicking on the respective button on the top right
  • Search for a specific team by typing on the top left field
  • Edit a team by clicking on it and assigning people

You can only assign existing collaborators that were added in the People screen as explained in the first part of this page. You can (and should) assign the same person to multiple teams. In most companies, people have multiple overlapping roles.

Note that by default there are already two teams for users and admins which contain the people you invited as collaborators.

With the teams in place, the final step is to create security policies.

Creating a security policy

To define security policies from the left sidebar of the Codefresh UI choose Account Settings and then click on the Permissions menu item under User Management

Kubernetes policies

Kubernetes policies

Here you can create new security rules using the who, what, where pattern. For each rule you select:

  1. The team the rule applies to,
  2. Cluster privileges (Create/delete/read/update) or pipeline privileges (Create/delete/read/run/update), and
  3. The effective tags (multiple tags can be used).

This way you can define any policy you wish per departments, projects, roles etc. for cluster/pipeline access.

There are two custom tags that you can use in rules which are “special”:

  • untagged is a “tag” which refers to all clusters that don’t have any tag.
  • * (the star character) means all tags.

Note that you cannot add any rules for administrators. Administrators by default have access to all clusters.

Description of privileges

For clusters:

  • Create - cluster creation requires someone to be account administrator anyway so currently this permission isn’t really necessary .
  • Read - can only see existing allowed clusters without any ability to change them.
  • Update - can see and edit existing allowed cluster resources (which means also perform installation, removal and rollbacks of Helm charts). Tags are managed from account settings, so this permission doesn’t apply to it currently.
  • Delete - cluster removal requires someone to be account administrator anyway so currently this permission isn’t really necessary.

For pipelines:

  • Create - can only create new pipelines, not see, edit (which includes tagging them) or delete them. This permission should also go hand in hand with additional permissions like read/edit untagged pipelines.
  • Read - view allowed pipelines only.
  • Update - see and edit allowed pipelines only (including tagging them).
  • Delete - can delete allowed pipelines only.
  • Run - can run allowed pipelines only.
  • Approve - resume pipelines that are waiting for manual approval.
  • Debug - allow the usage of the pipeline debugger.