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.
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.
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.
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 internal architecte detail, and we use our own CA. This setup reduces the risk of outages due to expired certs.
When configuring Central and supervisor Consoles, you must configure the supervisor Console to include the Subject Alternative Name (SAN) for the Central Console.
When configuring access to the Consoles via Ingress Network Routes in Kubernetes, you must add the Central Console to the supervisor Console Ingress configuration.
Central Console can have its own set of Defenders. In this case, these Defenders do communicate directly with Central Console. However, no project Defenders ever communicate directly with Central Console.
When users log into Prisma Cloud Console, they are presented with a list of projects to which they have access, and they can chose the project they want to work in. Access to projects is controlled by role-based access control rules.
You can grant access to specific projects for any 'local' users created in Console under
Manage > Authentication > Users. If you have integrated Console with an OpenLDAP, Active Directory, or SAML provider, you can grant access to projects by group. Users and groups can be granted access to multiple projects.
A user’s role is applied globally across all projects. That is, a user will have the same role for each project for which he has been granted access.
Project access control rules at the user level takes precedence over access control granted at the group level. For example, if a 'local' user has been granted access to project1, but also belongs to group1, which has been granted access to project2, he will only have permissions to access project1.
Prisma Cloud fully supports secrets management for tenant projects. Secrets management can be independently configured and managed for each tenant project.
Moving Defenders between projects is not supported. To "move" a Defender, decommission it from one project and deploy it to another.
Let’s look at how projects are provisioned.
Step 1:Install Console using any installation method. For example, you could install Console (onebox) with the or as a service in a Kubernetes cluster. When Console is installed, it runs in master mode by default.
Step 2:Install a second Console on a different host. By default, it also runs in master mode.
Step 3:In the UI for Console 1, provision a new project. Specify the URL to Console 2. The provisioning process automatically changes the operating mode for Console 2 to supervisor. The UI and API for Console 2 are now no longer directly accessible.
Step 4:The only difference between a master Console and a supervisor Console is whether its UI and API can be accessed directly, or whether it is proxied through the master. To view your tenant project (managed by Console 2), open Console 1 and select the project. All your rules and settings for your project are loaded and displayed in Console 1.
You can release a supervisor, and return it to its original state, by deleting the project. The supervisor Console reverts back to master mode.
If you have already deployed one or more stand-alone Consoles, and you want to adopt a project-based structure, then the migration is easy. Designate one Console as master, then designate each remaining Console as a supervisor by provisioning projects for them.
Adding an existing Console to a project is not a destructive operation. All data is preserved, and the process can be reversed. The only thing that changes is the way you access Console when it’s mode changes to supervisor. Supervisor Consoles cannot be accessed directly. They can only be accessed through the master Console, by selecting a project from the
Selected projectdrop-down list.
For example, assume you’ve deployed three separate stand-alone Consoles: one for your production environment, one for your test environment, and one for your development environment.
When migrating to projects, you have the following options:
Option 1:Promote one Console to master, and designate the others as supervisors. In this example, you pick the prod Console to be master, then create tenant projects for the test and development Consoles.
By default, Consoles run in master mode when they are installed, so you don’t need to do anything to "promote" prod to master. To relegate test and dev to supervisor, provision a project for each one.
Option 2:Install a new Console on a dedicated host and designate it as master. Provision a tenant project for each of the prod, test, and dev Consoles.
Accessing the API
All API requests should be routed to Central Console only. Central Console checks if the client has the correct permissions to access the given project, and then Central Console redirects the request to right supervisor, and then returns to supervisor’s response to the client.
For API requests that create, modify, or delete data, Central Console responds to the client with a success return code, and then updates the supervisor asynchronously.
Central Console reroutes the request to the appropriate supervisor. Not all requests need to be rerouted. For example, the endpoints for getting a list of users, groups, or projects are handled by Central Console directly. Some endpoints require no special permissions to access them, such as getting a list projects to which a user has been granted access.