You can assign roles to users to control their level of access to Twistlock. Roles determine what a user can do and see in Console, and the APIs he or she can access.
The following table summarizes the roles available in Twistlock.
Role | Access level | Typical uses case(s) |
---|---|---|
Administrator |
Full read-write access to all Twistlock settings and data. |
Security administrators. |
Operator |
Read-write access to all rules and data. Read-only access to user and group management, role assignments, and the global scan settings under Manage > System > Scan. |
Security operations teams. |
Defender Manager |
Read-only access to all rules and data. Can install and uninstall Defenders. |
DevOps and sysadmins for the nodes that Twistlock protects. |
Auditor |
Read-only access to all Twistlock rules and data. |
Auditors and compliance staff that need to verify settings and monitor compliance. |
DevOps User |
Read-only access to the Twistlock CI vulnerability and compliance scan reports only. |
Developer, Operations, and DevOps personnel that need to know about and/or address the vulnerabilities in the resources in your environment. |
Access User |
Install personal certificates only. |
Developers (and others) that use the nodes that Twistlock protects. |
CI User |
Run the Continuous Integration plugin only. |
CI Users can only run the plugin and have no other access to configure Twistlock. |
Let’s look at how two roles at the opposite end of the spectrum differ: Administrator and User. Administrators set the security policy. They decide who can run what Docker commands, and where they can be run. Users need to run Docker commands to do their job. Testers, for example, run Docker commands in the staging environment to test containers under development. Testers, however, have no business starting containers in the production environment. Administrators set a policy to assign testers the user role that lets testers run Docker commands in staging, but restricts their access to production.
If a user is assigned multiple roles, either directly or through group inheritance, then he is granted the rights of the highest role. For example, assume Bruce is part of GroupA and GroupB in Active Directory. In Console, you assign the Administrator role to GroupA and the Auditor role to GroupB.When Bruce logs into Twistlock, he will have Administrator rights. |
Roles are enforced the same way for both the Twistlock UI and the Twistlock API. |
To learn how to assign roles to users and groups, see Assigning roles.
This section describes all the roles Twistlock supports.
The Administrator can manage all aspects of your Twistlock installation. They have full read-write access to all Twistlock settings and data.
Administrators can:
Create and update security policies.
Create and update access control policies.
Create and update the list of users and groups that can access Twistlock.
Assign roles to users and groups.
The Admin role is reserved for security administrators.
When Administrators log into Console, they have access to the full dashboard. If you click on the profile button on the top right of the dashboard, you get the details of the currently logged in user (admin) and associated role (Administrator).
Operators can create and update all Twistlock settings. This role lets you view audit data and manage the rules that define your policies.
Operators cannot:
Create, update, or delete users or groups.
Assign or reassign roles to any user or group.
Change the global scan settings under Manage > System > Scan.
The Operator role is designed for members of your Security Operations team.
Defender Managers can install, manage, and remove Defenders from your environment. The Defender Manager role was designed to let members of your DevOps team manage the hosts that Twistlock protects without requiring Administrator-level privileges. To help debug Defender deployment issues, Defender Managers get read-only access to Twistlock settings and log files.
Defender Managers are typically members of your DevOps team. They need to manage the hosts that Twistlock protects, but they never need to alter any security policies.
Defender Managers are also typically used to automate the install of Defenders. If you use the API to programatically install new Defenders in an environment that is not orchestrated by Kubernetes or Swarm, create a service account with the Defender Manager role, then follow the instructions in Automate Defender install.
Auditors get read-only access to all Twistlock data, settings, and logs.
Auditors are typically members of your compliance team. They verify that your Twistlock setup meets your organization’s security requirements. To verify compliance, they must be able to see your settings, but they do not need to make changes to them.
DevOps Users get read-only access to the Jenkins Jobs and Twistcli Scans tabs under Monitor > Vulnerabilities and Monitor > Compliance. Each tab contains scan reports for images scanned using these tools. DevOps Users can use Twistlock scan reports and tools, for example, to determine why the CI/CD pipeline is stalled.
Additionally, DevOps users can use the CVE Viewer to query the Twistlock CVE database.
Users work with Docker containers. They run Docker client commands on the hosts that are protected by Defender. The commands they run include:
Pulling an image from a registry.
Starting a container on a host.
Stopping a container.
Users are typically members of your engineering team. For example, all members of your test team would be assigned the User role.
The following screenshot shows the view that user with the User role see when they log into Console. Users log into Console to get their client certificates, which they install on their machines to identify them. When a user runs a Docker command on a host, Defender checks that the user has the right permissions to run that command on that host.
The CI user role can be assigned to users that should only be able to run the plugin but have no other access to configure Twistlock or view data we have. It is designed to only provide the minimal amount of access required to run the plugins.
A CI user cannot log into the Console or even view the UI Dashboard. |