To help you get started with Projects, refer to these basic terms and concepts.
The following diagram describes the basic components within the project entity.
A project is an organizational management entity in the JFrog Platform for hosting your resources (repositories, builds, Release Bundle, and Pipelines, etc.) and associating users/groups as members with specific entitlements.
The JFrog Platform differentiates between assigned and unassigned resources in the scope of projects. When upgrading to the Platform with Projects, all the resources are set as 'Unassigned' as they have not yet been assigned to any project. To support assigning multiple resources to projects, you can assign projects to resources from the unassigned tab.
A unique Project Key that helps you identify and group your projects. For example, add a key that identifies the location of the project in the US Site or the type of team - the Developer Team. From Artifactory 7.42.1, the minimum number of characters required in Project keys has been reduced from 3 to 2.
Users or groups that are assigned a role in a project become a Project Member and are listed in the Members list for the project.
Resources are entities within the JFrog Platform including repositories, builds, and Pipelines. A set of product-specific actions are available if the product is installed on your system.
An Environment is used to aggregate project resources for simplified management of project resources (repository, Pipeline source, etc.) associated with either the DEV (Development) or PROD (Production) or both environments. It is mandatory to have at least one environment assigned to a resource and each resource is initially created in the DEV environment. You can assign a set of actions to the project members on each of the environments, providing you with an additional layer of role-based access granularity.
JFrog Platform users and groups can perform a set of actions in projects using a set of dedicated project-related RBAC roles including Global and project roles.
A set of dedicated project personas are set on the project level comprising of Global roles and Project roles. The main built-in role is the Project Admin role. By default, All Platform Administrators are automatically granted the Project Admin Role. For more information, see Project Roles and Members Concepts.
A Policy that can be used in a Global Watch or a Project Watch when you have a set of rules that apply to more that one project or on all projects in your organization. A Platform Admin, a Security Manager, and a users with Manage Policies permissions can create Global Policies.
A Watch that can be applied on resources in any project or unassigned resources that are not specific to a project. A Platform Admin, a Security Manager, and a user with Manage Watches permissions can create Global Watches. Starting from Xray 3.27.2, you can apply a Global Watch on a Project resource. For more information, see Global Watches
Create a Global Watch and Global Policy in the context of All:
Violations created by a Global Watch are not project specific, and will appear in the list of violations where the scanned resource resides, in any project. A user cannot ignore a violation from a Global Watch, only a Security Manager with the Ignore Global Watch Violations privilege can create a Global Ignore Rule.
Global Watches can only contain Global Policies.
A report that can be defined on all resources regardless of a project. A Platform Admin, a Security Manager, and a user with Manage Reports permissions can create Global Reports. Starting from Xray 3.27.2, you can create a Global Report on the Project scope. For more information, see Global Xray Reports.
A Policy that is created and used in the scope of a specific project. A Platform Admin, a Project Admin, a Security Manager, and a user with Manage Policies permissions can create project level Policies.
A Watch that is created and used in the scope of a specific project. A Platform Admin, a Project Admin, a Security Manager, and a user with Manage Watches permissions can create project level Watches.
Create a Project Policy and Project Watch in the context of the project you are in:
Violations created by a Project Watch are applicable to that specific project and will appear in the list of violations for a user within that project. Other users who are not members of the project will not see these violations. A user with Manage Watches permissions, a Platform Admin, a Project Admin, and a Security Manager can ignore a violation from a Project Watch.
A report that that can be defined on resources in a specific project. A Platform Admin, a Project Admin, a Security Manager, and a user with Manage Reports permissions can create project level Reports.
Projects is based on the JFrog RBAC (Role-based Access Control) mechanism that simplifies the notion of permission targets. Three main categories of roles are supported: Platform, Global, and Project roles. These roles enable users that have been assigned to these roles to perform a set of predefined actions associated with the role on all of the resources in the project.
The following Admin roles can manage projects and assign roles to project members and allocate resources:
Platform Admins are users that are set with the 'Administer the Platform' role and are referred to as Platform Admins in the scope of projects.
Project Admins are assigned by the Platform Admins to perform project-related admin tasks. To gain more flexibility, Project Admins can assign roles to different environments within a project. Each project comes with these predefined environments: DEV (Development) and PROD (Production). Resources in the JFrog Platform that are associated with Environment and Role Actions define the different access rights to the resources within each of the environments.
Roles replace permission targets, that are only available when upgrading from a previous version to the JFrog Platform supporting projects.
Global and Project roles allow Platform users and groups assigned with these roles to perform a full array of actions on their projects. A user or group becomes a project Member after they have been assigned at least one Global or Project role within a selected project. The roles are intended to manage the access rights of users or groups according to their role definition. The roles can include: Project Admin, Developer, Contributor, Release Manager, etc. The additional breakdown into Project roles provides flexibility when assigning different roles to the same user across the different projects. Project roles are more specific and represent access rights relevant to the specific project.
Global role-related procedures apply to all projects, whereas Project roles are project-specific and comprise of Global and Project roles. Global roles are assigned by the Platform Admin, whereas Project roles are defined by a Project Admin role. Global roles cannot be renamed or deleted; however the actions assigned to each role can be customized.
A project runs in either an DEV (Development) or PROD (Production) environment or both. You can assign a set of roles to project members on each of the environments, providing you with an additional layer of role-based access granularity.
Roles are cumulative, and are associated with a set of actions that allow users to have multiple roles within the predefined Platform hierarchy: Platform Administrators have the 'Administer the Platform' role and have full control over the entire platform including projects, while Project roles apply to specific projects or multiple projects. For example, a user can be a Project Admin for Project A and be assigned a Contributor role in Project B. In cases whereby there is a clash between roles at different levels, for example between a Global role and a project level, the project level role takes precedence.
Roles can be assigned two main types of actions:
CRUD Actions: A set of predefined CRUD Actions that can be applied at the Global role and Project role levels to each of the resources, including Read Artifacts, Write Artifacts, Delete Artifacts, and Delete Builds.
Product-based Actions: A set of product-specific actions are available if the product is installed on your system.
For example, if you have installed:
JFrog Xray: The Trigger security scans action is supported
JFrog Distribution: The Distribute Release Bundle action is supported
JFrog Pipelines: The Trigger Pipeline and Manage Pipelines actions are supported
The following section lists the different roles and their associated actions.
Start by planning your projects structure in the organization including the Global and Project roles. For more information, see Managing Project Roles and Members.
You can then proceed to create your first project.