We recommend that you register for a 30-day trial license code. Deep Security Smart Check will operate without an activation code; however, malware pattern updates will not be available and you will see a warning message in the administration console.
Contact us for full product licensing and pricing details.
Deep Security Smart Check uses the helm package manager for Kubernetes.
We recommend using Helm 3 (version 3.0.1 or later) to install Deep Security Smart Check if this is possible for you.
There is a handy guide that will help you get started. In most cases installing Helm 3 involves running a single command.
If you have already installed Deep Security Smart Check using Helm 2, you will need to migrate your install. The Helm folks have a helpful blog post that details this process.
If you have to use Helm 2, you will need helm version v2.14.1 or later. Expand this section for details.
There's a handy quickstart that will help you get started, or if you like living dangerously:
curl -L https://git.io/get_helm.sh | bashHelm has a cluster-side component called tiller that needs to be installed as well.
Make sure that your kubectl context is set correctly to point to your cluster:
kubectl config current-contextIf your kubectl context is not pointing to your cluster, use kubectl config get-contexts and kubectl config use-context to set it, or if you are using Google Cloud Platform follow the instructions in the Connect to the cluster dialog available by clicking the Connect button beside your cluster information in the console.
Configure a service account for tiller and install:
kubectl create serviceaccount \
--namespace kube-system \
tiller
kubectl create clusterrolebinding tiller-cluster-role \
--clusterrole=cluster-admin \
--serviceaccount=kube-system:tiller
helm init --service-account tillerUse helm version to confirm that you have at least version v2.14.1 of the client and server installed.
Note: the commands above will give tiller full cluster administrator privileges. Review Securing your Helm Installation for help on what to consider when setting up Helm in your cluster.
The Helm chart for Deep Security Smart Check is hosted in a public repository on Github.
To install the latest version of Deep Security Smart Check into the default Kubernetes namespace:
-
Create a file called
overrides.yamlthat will contain your site-specific settings.## activationCode is the product activation code. ## ## Default value: (none) activationCode: YOUR-CODE-HERE auth: ## secretSeed is used as part of the password generation process for ## all auto-generated internal passwords, ensuring that each installation of ## Deep Security Smart Check has different passwords. ## ## Default value: {must be provided by the installer} secretSeed: YOUR-SECRET-HERE
-
Use
helmto install Deep Security Smart Check with your site-specific settings:helm install \ --values overrides.yaml \ deepsecurity-smartcheck \ https://github.com/deep-security/smartcheck-helm/archive/master.tar.gz
Experienced helm users will note that we are using deepsecurity-smartcheck as the helm release name in these examples. There is no requirement to use this release name.
Note: This installs Deep Security Smart Check with an in-cluster database, which requires a persistent volume. Your cluster must support creating persistent volumes to work with the in-cluster database. See Use an external database to learn how to use an external database with Deep Security Smart Check.
The install process will display instructions for obtaining the initial username and password and for connecting to Deep Security Smart Check.
To upgrade an existing installation of Deep Security Smart Check in the default Kubernetes namespace to the latest version:
helm upgrade \
--values overrides.yaml \
deepsecurity-smartcheck \
https://github.com/deep-security/smartcheck-helm/archive/master.tar.gzYou can delete all of the resources created for Deep Security Smart Check by running helm delete:
helm delete deepsecurity-smartcheckUse the helm list command to list installed releases.
helm delete is a destructive command and will delete all of the Deep Security Smart Check resources. If you are not using an external database, you will also lose all database contents without further confirmation.
If you want to install a specific version of Deep Security Smart Check, you can use the archive link for the tagged release. For example, to install Deep Security Smart Check 1.2.44, you can run:
helm install \
--values overrides.yaml \
deepsecurity-smartcheck \
https://github.com/deep-security/smartcheck-helm/archive/1.2.44.tar.gzTo install Deep Security Smart Check into an existing Kubernetes namespace that's different from the current namespace, use the --namespace parameter in the helm install command:
helm install \
--namespace {namespace} \
--values overrides.yaml \
deepsecurity-smartcheck \
https://github.com/deep-security/smartcheck-helm/archive/master.tar.gzHelm uses a file called values.yaml to set configuration defaults. You can find detailed documentation for each of the configuration options in this file.
As described above, you can override the defaults in this file by creating an overrides.yaml file and providing the location of this file on the command line:
helm install \
--values overrides.yaml \
deepsecurity-smartcheck \
https://github.com/deep-security/smartcheck-helm/archive/master.tar.gzIf you create a file to override the values, make sure to copy the structure from the chart's values.yaml file. You only need to provide the values that you are overriding.
What role does my Google Cloud Platform service account need in order for Deep Security Smart Check to work with Google Container Registry?
The service account must have at least the StorageObjectViewer role.
If you are see errors from the auth service like:
request canceled while waiting for connection
the issue may be caused by a common Kubernetes installation issue where pods cannot talk to themselves using a Kubernetes service.
If you are using Google Kubernetes Engine, first ensure that network policy is enabled on your cluster.
If you are not using Google Kubernetes Engine, try the following command on all worker nodes in your cluster. If you are using minikube, use minikube ssh to access the worker node.
Depending on your installation, the network interface in the next step may be cni0 or docker0; if trying cni0 results in an error message, try docker0.
sudo ip link set cni0 promisc onIf you are using Amazon EKS and see errors like:
pod has unbound PersistentVolumeClaims
You likely have not defined a storage class. Since Amazon EKS does not create a default storage class you will have to create one as described here , then specify the storage class name when installing Deep Security Smart Check:
helm install \
--set persistence.storageClassName={storage class name} \
--values overrides.yaml \
deepsecurity-smartcheck \
https://github.com/deep-security/smartcheck-helm/archive/master.tar.gzIf you are attempting to add a registry that's running on a port other than the standard HTTPS port 443, you will likely run into timeouts.
The networkPolicy.additionalRegistryPorts configuration item in the Helm chart allows you to open outbound network access from Deep Security Smart Check to the registry.
For example, if your registry is running on port 8443, you would update your overrides.yaml file to include the following and do a helm upgrade to apply the changed configuration:
networkPolicy:
additionalRegistryPorts:
- 8443If you continue to encounter timeouts, the network connectivity issue may be caused by a firewall or some other network issue.
If you are installing Deep Security Smart Check with the built-in database on an Amazon Elastic Kubernetes Service (Amazon EKS) cluster running Bottlerocket, you may see errors with the db pod if the EKS EBS CSI driver is not installed:
Warning FailedMount 6m51s (x12 over 31m) kubelet, ip-192-168-82-134.us-west-2.compute.internal Unable to mount volumes for pod "db-74995d7886-rfl4g_default(6c9a66fd-5d7b-11ea-9306-0e4eadbaa154)": timeout expired waiting for volumes to attach or mount for pod "default"/"db-74995d7886-rfl4g". list of unmounted volumes=[data]. list of unattached volumes=[varrun tmp data]
Warning FailedMount 2m38s (x23 over 33m) kubelet, ip-192-168-82-134.us-west-2.compute.internal MountVolume.MountDevice failed for volume "pvc-6c53aaaa-5d7b-11ea-ae3f-02de703f8790" : executable file not found in $PATH
For production, you should use an external database instead of the internal database.
If you are doing a trial install and want to use the built-in database, you can install the required driver. See EKS EBS CSI Driver for more information and installation instructions.