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.
Helm charts, commonly referred to as the package manager for Kubernetes, are a simple method for distributing and managing applications in a Kubernetes environment. Helm charts share many similarities to package management tools such as npm (NodeJS), pip (Python), or gem (Ruby), where potentially complex installation routines are encapsulated using simple, text-based descriptions. Helm charts are built from some of the formats and technologies already used in or around Kubernetes, such as YAML and the Go template language, allowing for quick bootstrapping by seasoned professionals, while the uncomplicated structure is also approachable by Kubernetes neophytes.
For all of these reasons, and many more, Helm charts have rapidly grown in popularity, quickly becoming the de facto standard method for deploying applications to Kubernetes. Kubernetes has been a supported platform for Twistlock since our initial release, and we have naturally received many requests to produce a Helm chart since they began to rise to prominence. As a customer-focused company, we noted these requests and took action.
We previously provided an example Helm chart in recognition of the importance of this application distribution mechanism. However, that chart was provided as-is, primarily serving as a launching point for a Helm user who was interested in installing Twistlock using that method, and was not an officially supported installation mechanism. In addition, the sample chart only covered installation for Console, and did not include any capabilities for installing Defenders on the target cluster.
Installing Console and Defender with Helm charts
With the release of 19.03, we’ve introduced native support for generating Helm charts. This feature positions Helm as a fully supported installation method for Twistlock. In addition, this functionality has been seamlessly integrated with our install processes so that the charts are populated with site-specific configuration information at the time of their generation.
The standard method for installing Twistlock Console and Defenders into a Kubernetes cluster involves the versatile twistcli command-line utility. In that process, various configuration parameters that describe the properties of the target cluster and the desired state of the Twistlock components are passed to twistcli, which generates the YAML-formatted resource definitions that comprise the Twistlock services. The native Helm chart functionality extends the existing installation process, allowing for easy integration with any deployment procedures and automation routines that Twistlock users are already using in their environments.
The Helm client package and the Tiller cluster-side component must be installed and configured prior to attempting an installation of the Twistlock charts. The service account, role, and role-binding required by Tiller should also be defined and verified as working. The Helm Quickstart Guide provides a good overview of this process, as well as links to deeper explanations of the requirements and configuration options. Particular attention should be given to the guidance on securely deploying Tiller.
In the following example, the —helm argument is passed to twistcli, as well as the subcommand console export kubernetes and other flags that would typically result in the creation of the flat YAML file of Console resource definitions:
Rather than creating a flat text file containing the YAML definitions, twistcli has generated the gzipped tar archive twistlock-console-helm.tar.gz.
Looking into the contents of that archive, one can see the templates, Chart and values files that will be familiar to any Helm user:
The chart archive can be expanded and the individual files reviewed and edited if needed.
If no customization is required, the chart archive can be directly installed using the helm install command. In the following command example, one can see the creation of the various resources associated with Console:
Here, the status of the pod and service associated with Console are queried:
Console is now accessible and ready for the initial setup tasks:
Once the freshly-installed Console has been validated and the basic configuration applied, one can proceed to installing Defenders.
As with Console, the —helm flag is added to the standard twistcli invocation for generating the YAML definitions for Defender:
In this case, the Helm chart is stored in the archive twistlock-defender-helm.tar.gz.
Although the underlying resources differ, the installation of the Helm chart for Defender is identical to Console:
As Defender is deployed as a DaemonSet, one can see that a pod has been deployed to each of the hosts in the three-node cluster.
A query of the DaemonSet and pods associated with Defender shows that all resources are active and in the expected state:
Uninstalling the Twistlock Charts
Removing the Twistlock components from the target cluster is even more simple than their deployment.
To uninstall Console and Defender, the helm delete command is called against the release names that were used during the deployment (these names are available in the output of helm list):
In the previous example, helm delete is run against the twistlock-console and twistlock-defender releases. A query of the active namespaces reveals that the twistlock namespace is no longer active, indicating that all Twistlock resources have been removed from the cluster.
Twistlock, Helm, and the future
The newly-introduced native Helm chart support, fully integrated with the standard Twistlock installation procedure for Kubernetes, will enable users to more quickly and easily deploy and manage our components on their clusters. Helm charts are quickly becoming the standard method for delivering applications on Kubernetes, and are a natural fit for managing a cloud native, container-aware tool such as Twistlock.
In an ever-shifting technical landscape, tools like Helm charts will emerge in response to new needs and requirements, operational or otherwise. As the IT world changes, Twistlock will be there to meet any new challenges, and to respond to the needs of our users.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
Beyond App Security: Securing Applications No Matter Where They LiveRead the Blog
Surveying the Container Orchestration LandscapeRead the Blog
Building the Right Toolbox for a Successful DevSecOps CareerRead the Blog
BOD 19-02: DHS Vulnerability Remediation RequirementsRead the Blog
How Cloud Native Security is Adapting to New Hybrid Reality for EnterprisesRead the Blog