Helm is the package manager for Kubernetes, inspired by packaged managers such as homebrem, yum, npm and apt. Applications are packaged in Charts which are a collection of files that contain the definition and configuration of resources to be deployed to a Kubernetes cluster. Helm was created by Deis who donated the project to the Cloud Native Computing Foundation (CNCF).
Helm makes it simple to package and deploy applications to be deployed including versioning. upgrade and rollback of applications. Helm does not replace Docker images, in fact, docker images are deployed by Helm into a Kubernetes cluster.
Helm is comprised of two components a server-side service running on the Kubernetes cluster called Tiller and the client-side component, Helm. Using helm applications, packaged as charts, can be deployed and managed using a single command:
$ helm install myAppWe have recently packaged the Anchore Engine as a Helm Chart to simplify deployment on Kubernetes. Now Anchore can be installed in a highly scalable environment with a single command.
Within 3 minutes you can have an Anchore Engine installed and running in your Kubernetes environment. The following guide requires:
- A running Kubernetes Cluster
- kubectl configured to access your Kubernetes cluster
- Helm binary installed and available in your path
Tiller, the server-side component of Helm, should be installed in your Kubernetes cluster. To installer Tiller run the following command:
$ helm init
$HELM_HOME has been configured at /home/username/.helm
Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.
⎈ Happy Helming! ⎈If Tiller has already been installed you will receive a warning messaging that can safely be ignored.
Next, we need to ensure that we have an up to date list of Helm Charts.
$ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Skip local chart repository
...Successfully got an update from the "stable" chart repository
Update Complete. ⎈ Happy Helming!⎈By default, the Anchore Engine chart will deploy an Anchore Engine container along with a PostgreSQL database container however this behavior can be overridden if you have an existing PostgreSQL service available.
In addition to the database, the chart creates two deployments
- Cores Services: The core services deployment includes the external API, notification service, Kubernetes webhook, catalog and queuing service.
- Worker: The worker service runs the image analysis and can be scaled up to handle the concurrent evaluation of images.
In this example, we will deploy the database, core services and a single worker. Please refer to the documentation for more sophisticated deployments including scaling worker nodes.
The installation can be completed with a single command:
$ helm install --name anchore-demo stable/anchore-engineIf there server-side component, Tiller, is not installed you will see the following error message:
Error: could not find tiller
You may wish to configure Anchore Engine to synchronize policies from the Anchore Cloud service, allowing you to use the free graphical policy editor to build policies, whitelists and map these to your own repositories and images.
If you have not already created an account on the Anchore Cloud you can sign up for free at anchore.io/signup
We can pass your username and password to the Helm chart in either by using command line options or by creating a values.yaml file containing these parameters.
In the following example, the anchore.io username and password are being passed using command line options.
Note: In addition to passing your authentication credentials we also need to enable synchronization of policy bundles and disable anonymous access.
$ helm install --name anchore-demo stable/anchore-engine
--set coreConfig.policyBundleSyncEnabled=True
--set globalConfig.users.admin.anchoreIOCredentials.useAnonymous=False
--set globalConfig.users.admin.anchoreIOCredentials.user=[email protected]
--set globalConfig.users.admin.anchoreIOCredentials.password=verysecretAlternatively, the updated values file can be passed as a parameter to the installation.
$ helm install --name anchore-demo stable/anchore-engine --values=values.yamlIn both examples the --name parameter is optional and if omitted a name will be randomly assigned to your deployment.
The Helm installation should complete in a matter of seconds after which time it will output details of the deployed resources showing the secrets, configMaps, volumes, services, deployments and pods that have been created.
In addition, some further help text providing URLs and a quick start will be displayed.
Running helm list (or helm ls) will show your deployment
$ helm ls
NAME REVISION UPDATED STATUS CHART NAMESPACE
anchore-demo 1 Wed Jan 20 10:46:10 2018 DEPLOYED anchore-engine-0.1.0 defaultWe can use kubectl to show the deployments on the Kubernetes cluster.
$ kubectl get deployments
NAME DESIRED CURRENT UP-TO-DATE AVAILABLE AGE
anchore-demo-anchore-engine-core 1 1 1 0 1m
anchore-demo-anchore-engine-worker 1 1 1 1 1m
anchore-demo-postgresql 1 1 1 1 1mWhen the engine is started for the first time it will perform a full synchronization of feed data, including CVE vulnerability data. This first sync may last for several minutes during which time the service will be responsive but will queue up images for analysis pending successful completion of the feed sync.
The Anchore Engine exposes a REST API however the easiest way to interact with the Anchore Engine is through the Anchore CLI which can be installed using Python PiP.
$ pip install anchorecliDocumentation for installing the CLI on Mac, Linux and Windows can be found in the wiki.
The Anchore CLI can be configured using command line options, environment variables or a configuration file. See the getting started wiki for details.
In this example, we will use environment variables.
ANCHORE_CLI_USER=admin
ANCHORE_CLI_PASS=foobarThe password can be retrieved from Kubernetes by accessing the secrets passed to the container.
ANCHORE_CLI_PASS=$(kubectl get secret --namespace default anchore-demo-anchore-engine -o jsonpath="{.data.adminPassword}" | base64 --decode; echo)Note: The deployment name in this example, anchore-demo-anchore-engine, was retrieved from the output of the helm installation or helm status command.
The helm installation or status command will also show the Anchore Engine URL, for example:
ANCHORE_CLI_URL=http://anchore-demo-anchore-engine.default.svc.cluster.local:8228/v1/To provide external access you can use kubectl to expose the external API port, 8228 to the internet.
$ kubectl expose deployment anchore-demo-anchore-engine-core
--type=LoadBalancer
--name=anchore-engine
--port=8228service "anchore-engine" exposed
The external IP can be retrieved from the Kubernetes cluster using the get service call:
$ kubectl get service anchore-engine
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
anchore-engine 10.27.245.63 <pending> 8228:31622/TCP 22sIf the external IP is shown as pending then try re-running the command after a minute.
$ kubectl get service anchore-engine
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE
anchore-engine 10.27.245.63 35.186.160.168 8228:31622/TCP 49sIn this example the Anchore URL should be set to:
ANCHORE_CLI_URL=http://35.186.160.168:8228/v1Now you can use the Anchore CLI to analyze and report on images.
For example:
To view the status of the Anchore Engine:
$ anchore-cli system statusTo add an image to be analyzed:
$ anchore-cli image add docker.io/library/alpine:latestTo list images:
$ anchore-cli image listTo list CVEs found in an image:
$ anchore-cli image vuln library/alpine:latest osYou can follow the Getting Started Guide to learn more about using the Anchore Engine including adding subscriptions, evaluating policies and inspecting images.
