Access control

How to restrict resources in a company environment

Codefresh provides several complementary ways for access control within an organization.

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.

The third mechanism allows you to restrict the Git repositories used for loading pipeline definitions.

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 Users & Teams 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 Users & Teams menu item under User Management. Finally choose the second tab called Teams

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.

Security timeout

In the third tab - Security of the Users & teams screen you can set a timeout for users that perform no action in the Codefresh GUI. The minimum time period is 15 minutes but using the drop-down menu you can also define a number for hours and days.

Security timeout

Security timeout

Users will get a short warning 90 seconds before the last 15 minutes (if they are inactive for the defined time period). If they still perform no further actions the system will automatically log them out of Codefresh and they will have to login again in order to use the Codefresh GUI.

The maximum duration time you can set is 30 days.

Pipeline definition restrictions

By default, when a user creates a pipeline, the definition can be loaded from the inline editor or any private or public Git repository. You can restrict this behavior and allow only specific Git sources or even disable completely the loading of pipeline definitions from Git repositories.

The global pipeline settings are available at

Global pipeline restrictions

Global pipeline restrictions

In this screen there are toggle buttons for the following options:

  • Disable/Enable pipeline definitions defined using the inline editor of the Codefresh UI
  • Disable/Enable pipeline definitions from Git repositories connected to Codefresh
  • Disable/Enable pipeline definitions from any public URL

Clicking on any of the toggle buttons has a global effect. It will disable the respective GUI method during pipeline creation and will disable running of existing pipelines that use that method. For example if you disable the inline editor by clicking the first toggle, all existing pipelines that have their pipeline definition defined in the editor will be disabled (the run button will not be clickable).

For more fine-grained restrictions you can visit the Git integration screen of your Git provider and expand the YAML Options segment.

Pipeline restrictions per Git provider

Pipeline restrictions per Git provider

Here you can restrict the Git repositories that can be used for pipeline definitions

  • per git repository name (regex or manual selection)
  • branch name (regex)
  • folder name inside a git repository (glob pattern)

For example if you enter /^((pipeline-definition)$).*/g in the second field, then users will be able to load pipeline yamls only from a branch named pipeline-definition in a Git repository.