Harness provides Role-Based Access Control (RBAC) via user and group permissions. Users' login access is managed at the user level, and users' account and application permissions are managed via groups.
The following procedure adds a new user to a Harness account.
To add a user, do the following:
Mouseover Continuous Security, and click Access Management.
Click Users. The Users page appears.
Click Add User. The Add User dialog appears.
Enter the email address(es) that user will use to log into the Harness platform.
If you have User Groups defined, select the User Groups for this user. You can add a user before they are verified. You can also add this user to a group from the group's Add Members dialog when you manage the group.
Click SUBMIT. The user is added. The name provided for the user says user not registered.The user will receive a verification email at the address(es) you provided. When the user logs into Harness, the user creates a password, the email address is verified, and the user name is updated. You can reset the password in the user's information in Users.
To Add a User Group
The following procedure creates a new User Group and defines permissions for its users:
Mouseover Continuous Security, and click Access Management.
Click User Groups. The User Groups page appears.
Create the User Group.
Click Add User Group. The Add User Group dialog appears.
Enter a name and description for the new User Group, and click SUBMIT. The management page for the new group appears.
Add users to the group.
Click Member Users. The Add Members dialog appears.
Click in the text area and select the members for the group, and then click SUBMIT. The Member Users section of the group page is updated with the new members.
Set Account Permissions.
In Account Permissions, enable one or more of the account permissions for this group. For most users, you will enable only the Create/Delete Application permissions. For more information, see Permissions.
Add Application Permissions.
Click Add Permissions. The Add Application Permission dialog appears.
In Permission Type, select the permissions to apply to the group. These are the Harness components you want the group's members to use. For example, if you click Services, you can then use the Filter field to select the services on which the permission will apply. (For details, see Permissions below.)
In Application, select the applications where the permission will apply.
In Filter, select the entities (within the applications you selected in Application) that the group can use.
In Action, select the action(s) you want to authorize the group to perform.
Click SUBMIT. The User Groups page's Application Permissions section is updated.
Permissions
Both sets of Permissions—Account Permissions and Application Permissions—are set on each group. Before setting these permissions, it's important to understand how they interact with each other:
Account permissions affect the high-level permissions for the users in a group, such as the ability to add an application, manage users and groups, and manage their account.
Application permissions affect the low-level permissions for the users in a group, such as the ability to place Usage Scope on a secret that applies to a specific service.
For most users, you will want to apply Application permissions. Accountpermissions are primarily for administration.
Permissions Are Additive
When a Harness User is a member of two of more User Groups, that user's permissions are a union (a combination) of both User Groups' permissions.
Permissions Example
A user group might have the Account permission to add an application, but only the Application permission to add services:
Users in this group will be able to create applications and add Services to them, but not will not be able to add Environments, Workflows, or other Application components.
Account Permissions
Account-level permissions are enabled in each User Group page, under Account Permissions.
Account permissions enable the following Harness features:
Account Permission
Details
Manage Applications
You can create, update, and delete Applications in your account. For the group to add entities to the Application, you must add Application Permissions.
Read Users and Groups
Read-only permission for the Users and User Groups in Access Management.
Manage Users and Groups
Create, update, and delete Users and User Groups.
Manage Template Library
Create, update, and delete Account Level Templates in the Template Library.
Secrets in Delegate Profiles: If you have Administer Other Account Functions enabled, you can use the Scope to Account feature of encrypted text and files secrets, and use those secrets in Delegate Profiles for usernames, passwords, etc. See Using Secrets in a Profile.
Access Management: Configure Single Sign-On (SSO), IP Whitelist, and API Keys; set up and enforce Two Factor Authentication, and enforce password strength.
Create, update, and delete Cloud Providers. If this permission is not enabled, the users within the user groups will be able to only view the Cloud Providers and their settings.
Add, update, and delete Secrets Managers. If this permission is not enabled, the users within the user groups will be able to only view the list of Secrets Managers.
Manage Secrets
Add secrets for any Applications on which the user has the necessary Application Permissions. If this permission is not enabled, the users within the user groups will be able to only view the Secrets (Encrypted Text and Encrypted Files).
Enables User Group members to add, update, and configure Harness Delegates for the account.
Manage Delegate Profiles
This feature is coming soon.
Enables User Group members to add, update, and configure Delegate Profiles.
Application Permissions
Application permissions enable you to perform any activity on an Application level. This includes applying Secrets Management and some Account settings to specific Applications and Environments, via Usage Scope. It also includes adding and modifying Tags on Application components.
Restricting Usage
You can restrict who can apply settings—such as Secrets Management and some Account settings—to specific Application entities. These are set up in the Usage Scope section of the corresponding setting's dialog. For example, here is the Usage Scope section of an Artifact Server dialog:
In this case, the Artifact Server may be used by the ExampleApp Application in both K8s-GCP and dev Environments.
For a User to modify Usage Scope, the User must belong to a Group that has read and updateApplication permissions for the Application and components on which the restrictions are placed.
In Usage Scope, click the drop-down under Applications, and click the name of the Application.
In Environments, click the name of the Environment.
Production and Non-Production Pipelines and Permissions
You can filter the permissions to include either a Production Pipeline or a Non-production Pipeline.
When a Pipeline contains only all non-production stages, it is called as a Non-production Pipeline.
If a non-production environment is selected for the permission, the user will be able to trigger the pipeline as long as all the stages are deployed to non-production environments.
If a Pipeline has both non-production and production stages, the user needs to have access to all the production and non-production Environments to be able to trigger the Pipeline.
