Logon settings
Table of Contents
Self.Hosted 31.xx
Expand all | Collapse all
-
- Getting started
- System Requirements
- Cluster Context
-
- Prisma Cloud Container Images
- Kubernetes
- Deploy the Prisma Cloud Console on Amazon ECS
- Console on Fargate
- Onebox
- Alibaba Cloud Container Service for Kubernetes (ACK)
- Azure Container Service (ACS) with Kubernetes
- Azure Kubernetes Service (AKS)
- Amazon Elastic Kubernetes Service (EKS)
- IBM Kubernetes Service (IKS)
- OpenShift v4
-
- Defender Types
- Manage your Defenders
- Redeploy Defenders
- Uninstall Defenders
-
- Deploy Orchestrator Defenders on Amazon ECS
- Automatically Install Container Defender in a Cluster
- Deploy Prisma Cloud Defender from the GCP Marketplace
- Deploy Defenders as DaemonSets
- VMware Tanzu Application Service (TAS) Defender
- Deploy Defender on Google Kubernetes Engine (GKE)
- Google Kubernetes Engine (GKE) Autopilot
- Deploy Defender on OpenShift v4
-
- Agentless Scanning Modes
-
- Onboard AWS Accounts for Agentless Scanning
- Onboard Azure Accounts for Agentless Scanning
- Configure Agentless Scanning for Azure
- Onboard GCP Accounts for Agentless Scanning
- Configure Agentless Scanning for GCP
- Onboard Oracle Cloud Infrastructure (OCI) Accounts for Agentless Scanning
- Configure Agentless Scanning for Oracle Cloud Infrastructure (OCI)
- Agentless Scanning Results
-
- Rule ordering and pattern matching
- Backup and Restore
- Custom feeds
- Configuring Prisma Cloud proxy settings
- Prisma Cloud Compute certificates
- Configure scanning
- User certificate validity period
- Enable HTTP access to Console
- Set different paths for Defender and Console (with DaemonSets)
- Authenticate to Console with Certificates
- Configure custom certs from a predefined directory
- Customize terminal output
- Collections
- Tags
- Logon settings
- Reconfigure Prisma Cloud
- Subject Alternative Names
- WildFire Settings
- Log Scrubbing
- Clustered-DB
- Permissions by feature
-
- Logging into Prisma Cloud
- Integrating with an IdP
- Integrate with Active Directory
- Integrate with OpenLDAP
- Integrate Prisma Cloud with Open ID Connect
- Integrate with Okta via SAML 2.0 federation
- Integrate Google G Suite via SAML 2.0 federation
- Integrate with Azure Active Directory via SAML 2.0 federation
- Integrate with PingFederate via SAML 2.0 federation
- Integrate with Windows Server 2016 & 2012r2 Active Directory Federation Services (ADFS) via SAML 2.0 federation
- Integrate Prisma Cloud with GitHub
- Integrate Prisma Cloud with OpenShift
- Non-default UPN suffixes
- Compute user roles
- Assign roles
-
- Prisma Cloud Vulnerability Feed
- Scanning Procedure
- Vulnerability Management Policies
- Vulnerability Scan Reports
- Scan Images for Custom Vulnerabilities
- Base images
- Vulnerability Explorer
- CVSS scoring
- CVE Viewer
-
- Configure Registry Scans
- Scan Images in Alibaba Cloud Container Registry
- Scan Images in Amazon Elastic Container Registry (ECR)
- Scan images in Azure Container Registry (ACR)
- Scan Images in Docker Registry v2 (including Docker Hub)
- Scan Images in GitLab Container Registry
- Scan images in Google Artifact Registry
- Scan Images in Google Container Registry (GCR)
- Scan Images in Harbor Registry
- Scan Images in IBM Cloud Container Registry
- Scan Images in JFrog Artifactory Docker Registry
- Scan Images in Sonatype Nexus Registry
- Scan images in OpenShift integrated Docker registry
- Scan Images in CoreOS Quay Registry
- Trigger Registry Scans with Webhooks
- Configure VM image scanning
- Configure code repository scanning
- Malware scanning
- Windows container image scanning
- Serverless Functions Scanning
- VMware Tanzu Blobstore Scanning
- Scan App-Embedded workloads
- Troubleshoot Vulnerability Detection
-
- Compliance Explorer
- Enforce compliance checks
- CIS Benchmarks
- Prisma Cloud Labs compliance checks
- Serverless functions compliance checks
- Windows compliance checks
- DISA STIG compliance checks
- Custom compliance checks
- Trusted images
- Host scanning
- VM image scanning
- App-Embedded scanning
- Detect secrets
- OSS license management
-
- Alert Mechanism
- AWS Security Hub
- Cortex XDR alerts
- Cortex XSOAR alerts
- Email alerts
- Google Cloud Pub/Sub
- Google Cloud Security Command Center
- IBM Cloud Security Advisor
- JIRA Alerts
- PagerDuty alerts
- ServiceNow alerts for Security Incident Response
- ServiceNow alerts for Vulnerability Response
- Slack Alerts
- Splunk Alerts
- Webhook alerts
- API
Logon settings
You can control how users access Prisma Cloud with logon settings.
Setting Console’s token validity period
Prisma Cloud lets you set up long-lived tokens for access to the Console web interface and the API.
For security, users are redirected to the login page when an inactive Console session exceeds a configurable timeout.
By default, the timeout is 30 minutes.
This configurable timeout value also controls the validity period for API tokens.
For Console web interface tokens:
- If a user explicitly logs out, the claim to access Console is revoked.
- If Console is restarted, all users are automatically logged out.
Setting Console’s token validity period
Tokens are issued to control access to both Console’s web interface and the API.
You can set a timeout for Console sessions and a validity period for API tokens.
- Open Console.
- Go toManage > Authentication > Logon.
- Specify a value forTimeout for inactive Console sessions.This value controls:
- Time, in minutes, that a Console session can be inactive. After the timeout expires, the user is redirected to the login page. In an active session, the token is automatically renewed when the time elapsed is greater than or equal to half the timeout value.
- Time, in minutes, that an API token is valid. After the token expires, a new one must be retrieved.The maximum value permitted forTimeout for inactive Console sessionsis 71580 minutes.
- ClickSave.After you save your changes, Console redirects you to the login page for your changes to take effect.
Single sign-on to the Prisma Cloud Support
Prisma Cloud can allow single sign on and contextual help from the "?" button in the upper right hand corner of each Console page.
Our https://docs.twistlock.com site allows access when a valid token is issued from the Customer.
Or in this case, the "?" contextual links can embed the token into the URL used to access the page.
- Open Console.
- Go toManage > Authentication > Logon.
- Set the toggle forEnable context sensitive help and single sign on to the Twistlock Support site.When set to on (default), the token will be embedded into the contextual help link. when set to off, it will not be and you will need to enter the token manually.
- ClickSave.After saving your changes, Console redirects you to the login page for your changes to take effect.
Basic authentication to Console and API
Twistlock lets you disable basic authentication to the Console and API. Basic authentication is used in connections from twistcli, the API, and Jenkins.
With twistcli, you need to use the '--token' option to authenticate with the Console for image scanning and other operations that access Console.
This is the same token you receive form the /api/v1/authenticate API endpoint.
For more information, see the API documentation.
With the API, you would have use the authenticate endpoint to generate an authentication token to access any of the endpoints. Accessing the APi with Basic Authentication would not be allowed.
With Jenkins, there is no option at this point to use the Jenkins plugin and have basic authentication disabled. An option would be to use twistcli within Jenkins. this would require a step in the pipeline to retrieve an authentication token from the API for the scan to be completed.
- Open Console.
- Go toManage > Authentication > Logon.
- Set the toggle forDisable basic authentication to Console and API.When set to on, basic authentication will be disabled for the Console and API. You will not loose access to the Console from the login page. All of your user account will still be active and will still have access to login to the Console.
- ClickSave.After saving your changes, Console redirects you to the login page for your changes to take effect.
Strict certificate validation in Defender
Twistlock Console provides Defender installation scripts which use curl to transfer data from Console.
By default, scripts copied from Console append the '-k' option, also known as '--insecure', to curl commands.
This option lets curl proceed even if server connections are otherwise considered insecure.
Console provides a global option to disable the '-k' argument for curl commands.
- Open Console.
- Go toManage > Authentication > Logon.
- Set the toggle forRequire strict certificate validation in Defender installation links.
- ClickSave.After saving your changes, Console redirects you to the login page for your changes to take effect.
Strong passwords for local accounts
Twistlock can enforce the use of a strong password.
A strong password has the following requirements:
- Cannot be the same as the username.
- Must be at least 12 characters.
- Must contain one of each of the following: uppercase character, lowercase character, number, special character.
- List of special characters: ~!@#$%^&*()-_=+|[{}];:'\",<.>/?"
- Open Console.
- Go toManage > Authentication > Logon.
- Set the toggle forRequire strong passwords for local accounts.When enabled, strong passwords are required for passwords of newly created accounts or when existing passwords are changed. Enabling this setting doesn’t force existing accounts to change their password or disable access to any accounts.
- ClickSave.After saving your changes, Console redirects you to the login page for your changes to take effect.