- 1. Overview
- 2. Terminology
- 3. When to use projects
- 4. Architecture
- 5. Provisioning flow
- 6. Migration strategies
- 7. Accessing the API
- 8. Provisioning a project
- 9. Decommissioning a project
- 10. Decommissioning disconnected projects
- 11. Deploying Defender DaemonSets for projects (Console UI)
- 12. Deploying Defender DaemonSets for projects (twistcli)
- 13. Deploying Defender DaemonSets for projects (API)
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.
|Starting in 20.12, each instance of Console supports up to 10,000 simultaneous Defender connections. With this capability, 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.
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 up to 10,000 Defenders. Tenant projects are like silos. Each tenant maintains its own rules and settings, separate from Central Console and any other tenant.
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.
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 twistlock.sh script 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.