This technical deep dive highlights key capabilities released as part of Twistlock 19.03. To learn more about what’s included with Twistlock 19.03, check out our full release blog post.
When it comes to cloud native workloads we all want to get the maximum resource utilisation while maintaining secure segregation of workloads and user access. With containers we want security, resiliency, efficiency, and cost effectiveness…amongst others.
Twistlock has already integrated these capabilities into the product, specifically since version 2.4, which was released in April 2018… and it also covers unlimited scalability. We call this set of features Projects, and as per NIST SP 800-190 it’s the only secure way to do multi-tenancy.
However, there is a need to provide secure and truly segregated workloads to a vast array of intersecting teams, who all have people potentially playing different roles on different projects, and thereby require a granular and configurable set of permissions and visibility into the platform.
Twistlock 19.03 introduces this type of granular and configurable permission management with Assigned Collections. Assigned Collections allow you get to take a Collection (which was released way back in 2017 with version 2.1), and then logically group hosts, images, containers, lots of things.
The difference is that now you can assign that to a specific user or group of users. Twistlock grabs the users and groups from your chosen authentication provider and mandates that they can only have access to the resources in their assigned collection. This is an expansion of the existing role-based access already in the product.
Technical Deep Dive
Let’s set the scene. I have a team who contribute to developing a business application, sock-shop.
There are 5 members on the team. Let’s look at these users in Twistlock:
Now I could also place these users in groups coming from LDAP or AD. I could also have these Collections with users or groups who have different Role Based Access Control.
As you can see from that screenshot, I have all my users in the same Role (Auditor) and added them to the Collections as users and not groups. I’m trying to keep things as clear as possible for this deep dive.
Let’s go through what’s in that screenshot.
We can ignore the ‘ashley’ user since he’s our admin. The other users are the ones we’re interested in for this discussion. As you can see in the Permissions column, each of our users has access to different collections. These will let them interact with different things.
Let’s examine how we could tailor what they can access with just Collections.
We can give Collections a name, a description, and a colour, to help visually and quickly differentiate from other collections. But that’s just the beginning, and the important piece is the many options and the use of wildcard asterisks that allows a wide range of configuration options for your Collection (the example above give that Collection visibility into the whole estate).
You could also be very specific, as seen in the next few examples of more granular permissions.
Here I’m saying:
When the container name starts with k8s_orders-db_orders-db …
And it’s based on a mongo image with any tag (notice the : before the *)
And it’s on one of my hosts which starts with k8s_prd
And it has the label name:orders-db
And it is in the sock-shop namespace
Then whoever gets added to that Collection will only see things which match the specific pattern!
In addition Assigned Collections works with all the new features we’re announcing with this release, including:
- Apps: that’s the new Cloud Native Network Firewall and Radar for Hosts.
- Functions: while not new in this release since we’ve secured serverless functions for a while now.
- RASP Defenders: definitely check out this blog post written by Neil Carpenter on the new RASP Defender also released in 19.03.
With all of this we can now control exactly what our team can see. If Jim (who manages the team or the business service) logs in then he gets to see the whole thing!
He can navigate down the list on the left and interact with the various things his role and his assigned collection let’s him access.
Let’s now switch to Roger’s view. Roger administers our databases and also has access to those services that talk to the databases:
Roger’s view of the world is obviously a much different picture.
Finally here’s Freddie’s view. Freddie is at the opposite end to Roger — he looks after the frontend service and then those services hanging off it!
I’ve only shown you the radar views (because the radar was already seriously awesome and we’ve only gone and added more… read more here).
These assigned collections work for all views and with your role. If you have read-only access to see vulnerability information and you are put in a role that limits you to one image, then you can guess what you will see! If you can’t guess what you will see please return to the top and read again.
Assigned Collections is not the most secure multi-tenant way of grouping resources. Read the NIST SP 800-190 doc and segregate out your container workloads onto separate kit and use Projects. That’s the very best way.
However, if you have an environment where the management burden of this segregation outweighs the risks then Assigned Collections is for you.
I wanted to finish with “We Are The Champions” but seeing as this is yet another excellent feature from all the developers in Twistlock team I’ll just say it as it appears to me – It’s a Kind of Magic!
- Twistlock Platform
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
How to Lock Down the Kernel to Secure the Container HostRead the Blog
One Chapter Ends, Another BeginsRead the Blog
The Greatest Security Risks Lurking in Your CI/CD PipelineRead the Blog
Cloud Platform Radar: Powerful Cloud Asset IdentificationRead the Blog
Securing Serverless Functions: Visibility with Serverless RadarRead the Blog