Projects
Some deployments must be compartmentalized for regulatory or operational reasons.
Projects solve the problem of multi-tenancy.
Each project, or tenant, consists of a Console and its Defenders.
Each project is a separate, compartmentalized environment which operates independently with its own rules and configurations.
Projects are federated behind a single master Console with a single URL.
For example, https://console.customer.com might be the URL for accessing the master Console UI and API.
Tenant projects are deployed, accessed, and managed from the single master Console.
You could deploy a tenant Console for each business unit, giving each team their own segregated environment.
Each team accesses their tenant through the master Console’s URL.
Role-based access control (RBAC) rules manage who can access which project.
When users log onto Prisma Cloud Central Console, they are shown a list of projects to which they have access and can switch between them.
Scale projects have been deprecated.
If you’ve deployed a scale project, see migration options for scale projects for more information about how to transition to a supported configuration.
Terminology
The following terms are used throughout this article:
- Central Console--Also known as the master Console or just master. This is the interface from which administrators manage (create, access, and delete) their projects.
- Supervisor--Secondary, slave Console responsible for the operation of a project. Supervisor Consoles are headless. Their UI and API are not directly accessible. Instead, users interact with a project from Central Console’s UI and API.
- Project (also tenant project, or just tenant)--Deployment unit that consists of a supervisor Console and it’s connected Defenders. Tenant projects are like silos. Each tenant maintains its own rules and settings, separate from Central Console and any other tenant.
When to use projects
Carefully assess whether you need projects.
Provisioning projects when they are not required will needlessly complicate the operation and administration of your environment.
1. Do you have multiple segregated environments, where each environment must be configured with its own rules and policies?
If yes, then deploy a tenant project for each environment.
2. If you choose not to use projects now, can you migrate to projects at a later time?
Yes.
Even if you choose not to use projects now, you’re not locked into that decision.
You can always migrate to projects at a later time.
For more information, see Migration strategies.
Architecture
Projects federate the UI and API for multiple Consoles.
For example, if you have three separate instances of Consoles for development, test, and production environments, projects let you manage all of them from a single Central Console.
With projects, one Console is designated as the master and all others are designated as supervisors.
Thereafter, all UI and API requests for a project are proxied through the master and routed to the relevant supervisor.
Supervisors do not serve a UI or API.
Connectivity
By default, the master and its supervisor Consoles communicate over port 8083.
You can configure a different port by setting MANAGEMENT_PORT_HTTPS in twistlock.cfg at install time.
All Consoles must use the same value for MANAGEMENT_PORT_HTTPS.
Communication between the master and supervisor Consoles must be direct, and cannot be routed through a proxy.
Defenders communicate with their respective supervisor Consoles.
Project Defenders never communicate directly with the Central Console.
Prisma Cloud CA signed certs are used for establishing the Central Console to supervisor Console communication link.
Since no user interacts with the supervisor Console directly, the link is an