Twistlock Initializationπ£
Overviewπ£
The initialization job will use the Twistlock API to perform various deployment and configuration tasks that cannot be achieved declaratively. These tasks include:
- Setting up an initial administrator user
- Installing and validating a license
- Configuring and deploying Twistlock Defenders on each node
- Setting up additional Twistlock users
- Creating vulnerability policies to alert on a severity threshold
- Creating compliance policies that align with templates (e.g. DISA STIG, NIST)
- Creating runtime policies
- Creating trusted image policies
- Enabling stdout logging
- Turning off telemetry
Prerequisitesπ£
In order to utilize the init job, the following must be configured in values.yaml:
# Pull secret for Iron Bank images
imagePullSecrets:
- name: insert_secret_name_here
console:
# Credentials for admin account
# If this is a new install, the account will be created
credentials:
username: insert_user_here
password: insert_pass_here
init:
enabled: true
Care should be taken to securely store the credentials in an encrypted format (e.g. key store, SOPS)
Additionally, a valid license is required to interact with the API. This can be provided in console.license
or manually installed.
SSOπ£
By setting sso.enabled: true
, you can configure SAML SSO without manually logging into the console. The provider type shibboleth
is set as default since this is recommended by Twistlock support. For SAML SSO to work with Twistlock, local Twistlock users have to be created after configuring SSO via the console (Manage -> Authentication -> Users
). Click the Add User
button to create a Twistlock user with the same name as the Keycloak user name and specify SAML
as the Authentication Method
. With the init script, SAML users can automatically be created by setting console.additionalUsers
.
Example:
additionalUsers:
- username: "test"
role: "devOps"
authType: "saml"
Usersπ£
By setting console.additionalUsers
, you can setup more users in Twistlock with various authentication types and roles. Refer to Prisma Cloudβs RBAC Guide for more information.
Setting console.updateUsers: true
will force the init job to update the userβs password, role, and auth type, regardless of changes made in the console. This setting can also be set to false
to only setup the user if it does not currently exist.
Defendersπ£
By setting defender.enabled: true
, Twistlock defender containers will be deployed on every node using a Daemonset. It is recommended that you set defender.clusterName
to help identify the defenders.
On Kubernetes systems that do not use the Docker daemon, you will need to change
defender.dockerSocket
. For example, withk3s
, this is set to/run/k3s/containerd/containerd.sock
After successful deployment, you should see twistlock-defender-ds
pods running in your cluster.
Refer to the Prisma Cloud Defender Documentation for more information on installing Defenders.
Policiesπ£
By setting policies.enabled: true
, Defender policies will be configured. This includes setting up Vulnerability, Compliance, and Runtime policies for Containers, Hosts/VMs, and Functions (Serverless).
It is recommended that you set policies.name
as this will be used to identify the policies created by the init job.
Policy settings were based on Cyber Recommended Configurations.
Vulnerabilitiesπ£
Setting policies.vulnerabilities.enabled: true
will setup the vulnerability policies. If enabled, the following Rules will be added to Twistlock:
- Images > Deployed
- Hosts > Running hosts
- Hosts > VM images
- Functions > Functions
Each rule will force the following settings:
- Rule name: set to
policies.name
- Alert threshold: set to
policies.vulnerabilities.alertThreshold
- Apply rule only when vendor fixes are available: true
All other settings will be preserved.
For more information on Vulnerabilities, refer to Prisma Cloudβs Vulnerability Management.
Complianceπ£
Setting policies.compliance.enabled: true
will setup the compliance policies. If enabled, the following Rules will be added to Twistlock:
- Containers and images > Deployed
- Hosts > Running hosts
- Hosts > VM images
- Functions > Functions
Each rule will force the following settings:
- Rule name: set to combination of
policies.name
andpolicies.compliance.templates
- Each template set will have its own rule
- Compliance actions:
- If a control is in the specified
policies.compliance.templates
set, the action is set to a minimum ofAlert
- If there are no controls matching the compliance set, controls at or above
policies.compliance.alertThreshold
will have their action set to a minimum ofAlert
- If an action is already set to
Block
, it will not be changed. - Changes are not made to controls that are outside the compliance set
All other settings will be preserved.
Refer to Prisma Cloudβs Compliance Documentation for further details.
Runtimeπ£
Setting policies.runtime.enabled: true
will setup the runtime policies. If enabled, the following Rules will be added to Twistlock:
- Container policy
- Host policy
- Serverless policy
Container Runtimeπ£
The container policy runtime rule will force the following settings:
- Rule name: set to
policies.name
- Anti-malware
- Prisma Cloud advanced threat protection: On
- Kubernetes attacks: On
- Suspicious queries to cloud provider APIs: On
- Processes
- Processes started from modified binaries: On
- Crypto miners: On
- Reverse shell attacks: On
- Processes used for lateral movement: On
- Child processes started by unrecognized parents: On
- Processes started with SUID: On
- Networking
- Networking activity from modified binaries: On
- Port scanning: On
- Raw sockets: On
- File System
- Change to binaries and certificates: On
- Detection of encrypted/packed binaries: On
- Changes to SSH and admin account configuration files: On
- Binaries with suspicious ELF headers: On
- Custom Rules
- Detect privileged management tools starting in a container: Selected
- Detect usage of common data exfiltration ports: Selected
- Detect access to common crypto miner pool ports: Selected
- Detect access to cloud platform metadata APIs (AWS/GCP/Azure): Selected
- Detect attempts to tamper with bash shell configuration: Selected
- Detect writes to linux password and shadow files: Selected
- Detect file writes under /etc folder (Host): Selected
- Detect file writes under /etc folder (Container): Selected
- Detect an execution of cron app: Selected
- A database server app spawned a new process other than itself: Selected
- Detect launching of suspicious networking scanning tool: Selected
- Detect launching of suspicious networking tool: Selected
- Detect user deletion: Selected
- Detect user modification: Selected
- Detect user creation: Selected
Each sectionβs βEnabledβ setting is not forced on. But, is on by default.
All other settings will be preserved.
Host Runtimeπ£
The host policy runtime rule will force the following settings:
- Rule name: set to
policies.name
- Anti-malware
- Deny process by category: Exploit tools, Persistent access, Password attacks, Sniffing and spoofing > If a tool is added to the list it will be preserved
- Log inspection
/var/log/auth.log
and regex/var/log/nginx/error.log
and regex/var/log/mongodb/mongod.log
and regex/var/log/postgresql/postgresql-*.log
and regex/var/log/mysql.err
and regex/var/log/apache2/error.log
and regex- Activities
- Docker commands: On
- Include read only Docker events: Checked
- New sessions spawned by sshd: On
- Commands run with sudo or su: On
- Track SSH events: On
- Custom Rules
- Detect privileged management tools starting in a container: Selected
- Detect usage of common data exfiltration ports: Selected
- Detect access to common crypto miner pool ports: Selected
- Detect access to cloud platform metadata APIs (AWS/GCP/Azure): Selected
- Detect attempts to tamper with bash shell configuration: Selected
- Detect writes to linux password and shadow files: Selected
- Detect file writes under /etc folder (Host): Selected
- Detect file writes under /etc folder (Container): Selected
- Detect an execution of cron app: Selected
- A database server app spawned a new process other than itself: Selected
- Detect launching of suspicious networking scanning tool: Selected
- Detect launching of suspicious networking tool: Selected
- Detect user deletion: Selected
- Detect user modification: Selected
- Detect user creation: Selected
Each sectionβs βEnabledβ setting is not forced on. But, is on by default.
All other settings will be preserved.
Serverless Runtimeπ£
The serverless policy runtime rule will force the following settings:
- Rule name: set to
policies.name
- General
- Prisma Cloud advanced threat protection: On
- Processes
- Crypto miners: On
- Block all processes except main process: On
- Networking
- Raw sockets: On
Each sectionβs βEnabledβ setting is not forced on. But, is on by default.
All other settings will be preserved
Additional runtime details can be found in Prisma Cloudβs Runtime Defense Documentation.
Trusted Imagesπ£
Trusted image policy provides a way to explicitly trust images in your environment (from a given registry) and configure behavior for other images.
By setting console.trustedImages.enabled: true
, a trusted image policy will be configured and set as the highest precedence rule. By default a group will be set up with the name Ironbank-Trusted
and a registry regex match of registry1.dso.mil/ironbank/*
that will be set as trusted. All other images will have the default effect of βAlertβ.
The name, registries (list), and effect can be adjusted if you are mirroring Ironbank to a different registry, want to trust a different set of images, or want to block all other images:
console:
trustedImages:
registryMatches:
- "registry1.dso.mil/ironbank/*"
- "my-apps-registry.com/*"
name: "My-Trusted"
defaultEffect: "block"
Existing rules/groups will be preserved if they exist. If an existing rule/group exists with the same name (name
) it will be deleted and replaced with an updated rule/group.
Misc Settingsπ£
TBD
Development Notesπ£
Twistlockβs console deployment does not have declarative settings for accounts, defenders, policies, miscellaneous settings, etc.
Operatorπ£
One solution is to use the Twistlock Operator. However, during evaluation, several issues were found that make the operator unfit for Big Bang use:
- Pre-deployment, a secret with an access token is required. But, the token is generated by the console when it is created. This means you need to deploy the console, get the token, then deploy the operator.
- HTTP port of the console is not exposed. We would need to use pass-through TLS for Istio to accommodate HTTPS.
- The operator does not have a Helm chart. Instead, it requires a series of deployment steps.
- There are no accommodations in the operator for additional configuration like
- Policy rules
- Additional user accounts
- Logging to stdout
APIπ£
The Twistlock API provides an extensive set of options for configuration. Behind the console GUI, the API is used to perform the deployments and configuration. Although writing and maintaining a shell script is not ideal, it is the best option available for declarative configuration.
Implementationπ£
The Helm chart values for initialization are stored in a few secrets that get mounted into the initialization container. In addition, the scripts are stored in a configmap and volume mounted.
The bash scripts heavily use curl
and jq
to interact with the API. The main script is twistlock-init.sh
and will call the other scripts based on whether each one is enabled. At a minimum, the credentials are used to retrieve an auth token and the license is verified to be current.