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.
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:
- Git Integrations
- External docker registry settings
- External Helm repositories
- Cloud provider settings
- Cloud storage settings
- Shared configuration
- API token generation
- SSO Settings
- Runtime environment selection
- Slack settings
- Team/Users settings
- ABAC for Kubernetes clusters
- Billing and charging
Only people with Administrator level have access to the respective UI screens.
Note however that Users can still control their own email notification settings, as well as access the internal Codefresh registry externally.
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:
- Assigning custom attributes to your Kubernetes clusters and/or pipelines
- Creating teams and assigning users to them
- 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.
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.
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
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.
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.
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
Here you can create new security rules using the who, what, where pattern. For each rule you select
- The team the rule applies to
- Cluster privileges (Create/delete/read/update) or Pipeline privileges (Create/delete/read/run/update)
- 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”:
untaggedis 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
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 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
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