Deploy Qlik Sense Enterprise On Kubernetes
Deploy Qlik Sense Enterprise On Kubernetes
HELP.QLIK.COM
© 2019 QlikTech International AB. All rights reserved. Qlik®, Qlik Sense®, QlikView®, QlikTech®, Qlik Cloud®, Qlik
DataMarket®, Qlik Analytics Platform®, Qlik NPrinting ®, Qlik Connectors®, Qlik GeoAnalytics®, Qlik Core®,
Associative Difference®, Lead with Data ™, Qlik Data Catalyst™, Qlik Associative Big Data Index™ and the QlikTech
logos are trademarks of QlikTech International AB that have been registered in one or more countries. Other
marks and logos mentioned herein are trademarks or registered trademarks of their respective owners.
Contents
For detailed information on Qlik Sense licensing options, see Qlik's legal terms, product terms, and Licensing
Service Reference Guide:
≤ Qlik Legal Terms
≤ Qlik Product Terms
≤ Qlik Licensing Service Reference Guide
Product activation
All Qlik products are entitled and enforced by a LEF (License Enabler File). The LEF is the artifact that is
downloaded during the production activation. A Qlik product is licensed and activated using either a serial and
control number, or a signed license key. The use of a signed license key is required for Qlik Sense Enterprise on
Cloud Services and Qlik Sense Enterprise on Kubernetes deployments, and for the use of capacity based licenses.
Unified license
As of the April 2019 releases of Qlik Sense and QlikView, Qlik Sense customers can use a unified license in multiple
deployments. A unified license shares the same signed key between:
Applying the same signed key to multiple deployments lets you share the same users and access types. Users can
access all connected deployments using the same Professional or Analyzer access allocation.
Access types
Access types licenses are the Professional and Analyzer Users licenses (user-based) and Analyzer Capacity
licenses (capacity-based). You can combine these for a subscription based license if you use the signed license
key when your deployment is activated. You can combine only user-based licenses if you are using a perpetual
license.
After changing to a license with a signed key, you cannot return to using the old LEF based license
model.
Token
You use tokens to allocate access passes to users so that they can access Qlik Sense. The License Enabler File
(LEF) determines the number of tokens that you can allocate to different access passes. A user without an access
pass cannot access apps.
With a Qlik Sense Token license you use tokens to allocate access passes to users. You can allocate user access
and login access.
The token license is available only to customers with existing Qlik Sense Token licenses.
Core-based site
Qlik Sense Enterprise core-based sites are licensed based on the number of CPU cores on which the software will
operate. A Core means a single processing unit within a processor or CPU, whether physical or virtual, including
a vCPU or virtual core, which is capable of executing a single software thread at a time.
Qlik DataMarket
Qlik DataMarket offers a collection of up-to-date data from external sources accessible directly from within Qlik
Sense. The available data includes current and historical weather and demographic data, currency exchange
rates, as well as business, economic, and societal data.
Qlik DataMarket has two license options, one free and one licensed. The free option gives you access to a limited
data set. The licensed option gives you access to premium data packages. You activate the license in the same
way as for Qlik Sense Enterprise by entering owner information, serial number, and control number.
It is not necessary to accept Qlik DataMarket terms and conditions when using Qlik Sense Desktop.
Access credentials are also not required because the premium data sets are not available on Qlik
Sense Desktop.
Qlik NPrinting
You can install and configure Qlik NPrinting to connect to QlikView documents or Qlik Sense apps. The licensing
requirements and procedures are different depending on if you connect Qlik NPrinting to QlikView or Qlik Sense.
Qlik NPrinting versions 16.0.0.0 and later are licensed by a LEF. If you are using an earlier version of Qlik
NPrinting, we suggest that you upgrade to Qlik NPrinting versions 16.0.0.0 or later.
A Qlik Sense token is not required for the Qlik NPrinting service account. However, because you often
perform troubleshooting within the Qlik NPrinting service account, it is helpful to assign a token to
the Qlik NPrinting service account so that it has access to the Qlik Sense hub.
For detailed information on Qlik Sense licensing options, read Qlik's legal terms, product terms, and Licensing
Service Reference Guide:
≤ Qlik Legal Terms
≤ Qlik Product Terms
≤ Qlik Licensing Service Reference Guide
If you want to set up Qlik Cloud Services or Qlik Sense Enterprise on Kubernetes, please contact your
Qlik representative or Qlik Support to obtain a valid license for the setup.
Unified license
As of the April 2019 releases of Qlik Sense and QlikView, Qlik Sense customers can use a unified license in multiple
deployments. A unified license shares the same signed key between:
Applying the same signed key to multiple deployments lets you share the same users and access types. Users can
access all connected deployments using the same Professional or Analyzer access allocation.
A capacity-based license grants a predefined number of time allocations for accessing Qlik Sense Enterprise that
can be used by identified or anonymous users. In Qlik Sense, capacity-based licenses are either based on
Analyzer Capacity access, or Login access pass allocated with a Token license.
Access types
Access types licenses are the Professional and Analyzer Users licenses (user-based) and Analyzer Capacity
licenses (capacity-based). You can combine these for a subscription based license if you use the signed license
key when your deployment is activated. You can combine only user-based licenses if you are using a perpetual
license.
After changing to a license with a signed key, you cannot return to using the old serial and control
number license model.
l Professional access (user-based) is allocated to an identified user to allow the user to access streams and
apps within a Qlik Sense site. The professional access is intended for users who need access to all features
in a Qlik Sense installation. A user with professional access can create, edit, and publish sheets or apps,
and make full use of the available features, including administration of a Qlik Sense site.
l Analyzer access is allocated to an identified user to allow the user to access streams and apps in the hub.
The analyzer access is intended for users who consume sheets and apps created by others. A user with
analyzer access cannot create, edit, or publish sheets or apps, but can create and publish stories,
bookmarks and snapshots based on data in apps. The user can also create bookmarks, print objects,
stories, and sheets, and export data from an object to Excel.
l Analyzer capacity is a consumption-based license type, which is similar to analyzer access regarding
available features. Users can access streams and apps in the hub and consume sheets and apps created
by others. Analyzer capacity access allows users to create and publish stories, bookmarks, and snapshots
based on data in apps. Creating, editing, or publishing sheets or apps is not possible.
With an analyzer capacity license, you subscribe to analyzer time, a defined amount of minutes per
month (calendar date). These minutes are shared between users and can be consumed by anyone who is
part of the user group, including anonymous users. Consumption is measured in units of 6 minutes. For
each new 6-minute period, a unit is consumed.
To simplify assignment of access to users, you can enable dynamic assignment. Choose between four options:
You can upgrade from analyzer access to professional access, but not downgrade from professional to
analyzer.
If you change to a new license key, all your assignments are removed, because they are associated with the
license, not the tenant. However, if you start using the old license key again, the assignments will be present.
Token
You use tokens to allocate access passes to users so that they can access Qlik Sense. The License Enabler File
(LEF) determines the number of tokens that you can allocate to different access passes. A user without an access
pass cannot access apps.
The token license is available only to customers with existing Qlik Sense Token licenses.
There are two types of access passes that can be allocated using tokens:
l User access pass (user-based) is assigned to unique and identified users allowing them unlimited access
to apps, streams, and other resources.
l Login access pass (capacity-based) allocates a block of passes to a group for infrequent or anonymous
access. Allows full access for a limited period.
When you allocate tokens, the number of available tokens is reduced. Each access type costs a certain number of
tokens, and if the token balance is zero or insufficient, you cannot allocate more to the access types. You can
free up tokens and choose to use the tokens differently. The number of tokens for the Qlik Sense site can be
increased or decreased by activating a new license.
Core-based site
Qlik Sense Enterprise core-based sites are licensed based on the number of CPU cores on which the software will
operate. The license is administered using a License Enabler File (LEF), which limits the maximum number of
cores on which the Qlik associative engine and its components may operate. A Core means a single processing
unit within a processor or CPU, whether physical or virtual, including a vCPU or virtual core, which is capable of
executing a single software thread at a time.
When licensing Qlik Sense using a serial and control number, the LEF can be downloaded when the serial
number and the control number have been entered in the Qlik Management Console (QMC). The LEF can also be
pasted directly into the QMC, if, for example, no network connection is available. There are two license types that
can be activated using a serial and control number: Professional and Analyzer Users licenses, and Qlik Token
licenses.
When licensing Qlik Sense using a signed key, the LEF file is stored in the License Backend.
If you want to set up Qlik Cloud Services or Qlik Sense Enterprise on Kubernetes, please contact your
Qlik representative or Qlik Support to obtain a valid license for the setup.
Analyzer Capacity licenses (capacity based) can only be licensed using a signed key. When
combining professional, analyzer, and analyzer capacity access types in the same Qlik Sense
Enterprise installation, you must license it using a signed key.
Token license
You use tokens to allocate access passes to users so that they can access Qlik Sense. The License Enabler File
(LEF) determines the number of tokens that you can allocate, and holds the number of tokens available for the
central node in a site. This means that a Qlik Sense site needs at least one (1) LEF. A user without an access pass
cannot access apps.
The token license is available only to customers with existing Qlik Sense Token licenses.
You cannot use QlikView CAL-based licenses with Qlik Sense as the tokens are not compatible with
the Client Access Licenses (CALs) used in QlikView.
Increase in tokens
When the number of tokens in the LEF increases (for example, when buying additional tokens), the new tokens
are added to the pool of unallocated tokens that can be used to allocate access passes that allow users to access
Qlik Sense.
Decrease in tokens
When the number of tokens in the LEF decreases, the following happens:
Access assignment
Qlik Sense Enterprise licenses are based either on access types, or on tokens. Depending on
your license, you can allocate either access types or access passes to users, to allow them to
access Qlik Sense.
l Access types licenses are the Professional and Analyzer Users licenses (user-based) and Analyzer Capacity
licenses (capacity-based).
With a Professional and Analyzer Users license you can allocate professional access and analyzer access.
With an Analyzer Capacity license you can allocate analyzer capacity access, where consumption is time
based (analyzer time).
l With a Qlik Sense Token license you use tokens to allocate access passes to users. You can allocate user
access and login access.
Access types
Professional and Analyzer Users licenses and Analyzer Capacity licenses grant a predefined number of access
allocations. The License Enabler File (LEF) defines the terms of your license and the access types that you can
allocate to users. You can combine these for a subscription based license if you use the signed license key when
your deployment is activated. You can combine only user-based licenses if you are using a perpetual license. You
must use a license with a signed key if you are licensing analyzer capacity access.
Professional access
Professional access is allocated to an identified user to allow the user to access streams and apps within a Qlik
Sense site. The professional access is intended for users who need access to all features in a Qlik Sense
installation. A user with professional access can create, edit, and publish sheets or apps, and make full use of the
available features, including administration of a Qlik Sense site.
For Qlik Sense installations licensed with a serial and control number, if you remove professional access
allocation from a user, the access type is put in quarantine, if it has been used within the last seven days. If it has
not been used within the last seven days, the professional access is released immediately. You can reinstate
quarantined professional access, to the same user, within seven days.
Quarantine is not applicable for Qlik Sense installations licensed using a signed key.
The maximum number of parallel user connections for a single user of this type of access pass is five (5).If you
use a license with a signed license key, accessing the QMC also counts and adds to the maximum number of
parallel sessions, which is five. To avoid unnecessary session consumption, the root admin should not be
allocated any type of access.
When a user with the maximum number of parallel user connections ends a connection (for example, by logging
out) five minutes must pass before the user can use the access pass to add another connection (for example, by
logging in).
Analyzer access
Analyzer access is allocated to an identified user to allow the user to access streams and apps in the hub. The
analyzer access is intended for users who consume sheets and apps created by others. A user with analyzer
access cannot create, edit, or publish sheets or apps, but can create and publish stories, bookmarks and
snapshots based on data in apps. The user can also create bookmarks, print objects, stories, and sheets, and
export data from an object to Excel.
For Qlik Sense installations licensed with a serial and control number, if you remove analyzer access allocation
from a user, the access type is put in quarantine, if it has been used within the last seven days. If it has not been
used within the last seven days, the analyzer access is released immediately. You can reinstate quarantined
analyzer access, to the same user, within seven days.
Quarantine is not applicable for Qlik Sense installations licensed using a signed key.
The maximum number of parallel user connections for a single user of this type of access pass is five (5).When a
user with the maximum number of parallel user connections ends a connection (for example, by logging out)
five minutes must pass before the user can use the access pass to add another connection (for example, by
logging in).
With an analyzer capacity license, you subscribe to analyzer time, a defined amount of minutes per month
(calendar date). These minutes are shared between users and can be consumed by anyone who is part of the
user group, including anonymous users. Consumption is measured in units of 6 minutes. For each new 6-minute
period, a unit is consumed.
Access passes
With a Qlik Sense Token license you use tokens to allocate access passes to users. The License Enabler File (LEF)
determines the number of tokens that you can allocate to different access passes. A user without an access pass
cannot access apps.
The access pass is valid within an entire Qlik Sense site. For example, if a user first connects to a node in the USA
and then, at a later stage, connects to a node in the UK, the user consumes the same access pass, if the two
nodes are connected to the same central node.
The maximum number of parallel user connections for a single user of this type of access pass is five (5).When a
user with the maximum number of parallel user connections ends a connection (for example, by logging out)
five minutes must pass before the user can use the access pass to add another connection (for example, by
logging in).
One (1) token corresponds to one (1) access pass. The access passes are allocated using the Qlik Management
Console (QMC).
You can have both a user access pass and the possibility to consume login access passes. If you have
five active sessions, opening an additional session will consume from your login access passes.
l If an identified user is disconnected, the user can re-connect and continue to use the same access pass, if
re-connecting within the 60 minutes.
l If an anonymous user is disconnected, the user gets a new access pass when re-connecting.
The login access pass tracks the number of logins and runs over 28 days. For example, if 1000 logins are assigned
to Group A, the users in Group A can use 1000 logins over 28 days. If 100 logins are consumed on Day 1, the 100
logins are available again on Day 29.
The maximum number of parallel user connections for a single user of this type of access pass is five (5). Note
that this only applies to identified users. An anonymous user can only have one (1) user connection. When a user
with the maximum number of parallel user connections ends a connection (for example, by logging out) five
minutes must pass before the user can use the access pass to add another connection (for example, by logging
in). However, a user can have more connections than allowed by a single access pass by consuming additional
access passes.
One (1) token corresponds to ten (10) access passes. The access passes are allocated using login access groups in
the QMC.
App reloads will extend the session and consume access passes also when the app is not actively
used. If a browser page is open with an app, app reloads will result in additional access pass
consumption.
1. For every ten (10) unused login access passes, one (1) token is freed up.
2. For every ten (10) login access passes that leave the used state after the period specified in the Access
assignment (page 10) section above has passed, one (1) token is freed up.
System requirements
Check that your environment fulfills the system requirements.
Supported browsers
Check that your browsers are supported.
Multi-cloud services
Understand the Qlik Sense services.
The Kubernetes environment must have Internet access to the Qlik Helm and
Container Image repository.
Kubernetes
environments Kubernetes service vendors:
l Amazon Web Services (AWS) using Amazon Elastic Container Service for
Kubernetes (EKS)
l Amazon Web Services (AWS) deployed via Kubernetes Operations (KOPs)
l Google Cloud using Google Kubernetes Engine (GKE)
l Red Hat OpenShift 4+
Kubernetes package Helm greater than v2.12.0 and less than v2.15.x
manager
Windows: Minikube v0.33 +
Local/Evaluation/Test
Red Hat MiniShift v1.21.0+
environment
Mac: Docker for Desktop with Kubernetes enabled: v2.0.0.3
Each Qlik Sense release is tested for compatibility with the latest publicly available browser versions. Due to the
frequency of browser version updates, Qlik does not include specific browser version numbers in the system
requirements.
Each Qlik Sense release is compatible with and supported on the latest iOS versions that are publicly available at
the time of the Qlik Sense release. Due to the frequency of iOS version updates, Qlik does not include specific iOS
version numbers in the system requirements.
Microsoft Windows 7
l Microsoft Internet Explorer 11
l Google Chrome
l Mozilla Firefox (requires hardware acceleration, not supported in virtual environments)
Microsoft Windows 10
l Microsoft Edge
l Microsoft Internet Explorer 11
l Google Chrome
l Mozilla Firefox (requires hardware acceleration, not supported in virtual environments)
CefSharp embedded browser v55 or later (CefSharp allows you to embed the Chromium open source browser
inside .Net apps)
CefSharp embedded browser v55 or later (CefSharp allows you to embed the Chromium open source browser
inside .Net apps)
iOS
Version 11.2 or later (script editing is not supported on tablet devices).
Supported devices:
Supported browsers:
l Apple Safari
l Google Chrome
l VMware browser (using AirWatch per-app VPN)
l BlackBerry Access 2.9.1 or later (using BlackBerry Dynamics platform)
Android
Version 6.0, 7.1, 8.1 and 9.0 (script editing is not supported on tablet devices):
l Google Chrome
l BlackBerry Access 2.9.1 or later (using BlackBerry Dynamics platform)
Windows 10 phone
l Microsoft Edge
Minimum screen resolution for desktops and laptops is 1024x768; tablets is 1024x768; small screens is
320x568.
Multi-cloud services
You have several options when deploying a Qlik Sense Enterprise on Windows environment. The services that you
need to run in a multi-cloud deployment can be categorized as follows.
Typically the services running in a QCS deployment are similar to those running in a Qlik Sense Enterprise on
Kubernetes deployment but are not accessible, because Qlik manages the infrastructure. You can connect to
QCS SaaS but do not have the same configuration options as a Kubernetes deployment.
Service Description
App Distribution Distributes apps and associated metadata to defined distribution targets, based on
Service policy-based app distribution rules.
Hybrid Stores configuration details including credentials and URLs for all target environments
Deployment in a multi-cloud deployment.
Service
Hybrid Setup Multi-cloud Setup Console UI functions for managing target environments configured in
Console Service a multi-cloud deployment including credentials and service URLs.
Resource Publishes installed extensions and themes to the Resource Library in each cloud
Distribution environment.
Service
Service Description
Chronos Scheduler back end service.
Cloud hub Serves the hub functionality to users in Qlik Cloud Services and Qlik Sense Enterprise
on Kubernetes.
Collections Organizes and structures content supplied to the hub. It also applies access control
rules.
datafiles Allows user to upload/manage data files that can be accessed during reload of an
app.
edge-auth Service that works together with external Identity Providers to authenticate users
upon entry to the deployment. Also manages tickets that authorize secure access to
internal resources.
elastic-infra A collection containing non-Qlik services: MongoDB, Redis, and nginx-ingress. It
bootstraps an elastic-infra deployment on a Kubernetes cluster using the Helm
package manager. It starts up the basic resources needed to connect all the
components and functionality required in a cloud environment.
Engine Handles all application calculations and logic.
Feature Flags Responsible for toggling features on and off in advanced scenarios.
Insights REST service for the functionality behind the “Share” dialog on a sheet. The service is
responsible for sharing Qlik Sense insights by generating, tracking and serving
persistent permalinks to the shared resources. Permalinks can be shared in various
social media.
Licenses The license service is used to enforce user licensing in Qlik Cloud Services and Qlik
Sense Enterprise on Kubernetes.
Locale Handles user locale selection for the client.
Mira Provides a discovery service for Engines in the deployment, their current health, and
availability of applications.
ODAG Service for on-demand app generation of Qlik Sense apps.
Policy Decision Processes a set of rules on Qlik Cloud Services and Qlik Sense Enterprise on
Kubernetes that perform ABAC security evaluation against Qlik objects (for example,
apps). It is sometimes referred to as the Rules Service. It uses a REST API for the rules
engine and management API for rule based policies and replaces the QRS Rules
Engine, Policy Decision Service.
qix-data- Handles engine requests for connection management.
connection
qix-sessions Responsible for routing user session traffic to the Engine services.
Reporting Implements the productions of Reports with data and chart images.
Resource Library A general-purpose resource storage service for supporting content such as themes
and extensions.
Tenant Used to store and return tenant (user) information.
temporary- Manages resources that are made available temporarily.
contents
User Responsible for managing and retrieving user information.
Sense Client The Desktop and web browser instance of the Qlik Sense client run by developers on
Qlik Sense Enterprise and by consumers on QCS and Qlik Sense Enterprise on
Kubernetes.
To ensure that Qlik Sense Enterprise on Kubernetes APIs are protected against CSRF security risks, Qlik has
implemented token-based anti-CSRF security for its APIs that will prevent CSRF attacks.
This token is generated on the server-side and is linked to a specific session by the web server, which is then used
as a hidden value in every web application form. Since the token is on the server side and not in the web session,
a hacker has no way to get that token because they do not have access.
l A running Kubernetes cluster – this can be run locally for development purposes or deployed to cloud
vendors including AWS, Google Cloud and Azure.
l The Kubernetes cluster must have access to file storage to persist data. This should be provided as a
Storage Class that allows readwritemany access. You will need the name of this Storage Class when
installing.
l You also require a license key for Qlik Sense Enterprise and this must be in the signed license key format.
A serial number and control number cannot be used.
Contact Qlik support if you do not have this version of your license.
The Qlik documentation does not cover the installation and configuration of a Kubernetes cluster and you
should review the documentation for this at either https://Kubernetes.io or for the cloud vendor or product you
are using.
You will also need the following tools installed on your local machine to interact with your Kubernetes
environment, issue commands and deploy software:
l Kubectl - Install kubectl on the machine you will run admin commands from. You can find further details
for your operating system at https://Kubernetes.io.
This can point to different clusters if you have more than one. Ensure that the commands go
to the right Kubernetes instance.
l Helm - Helm is a package manager built for Kubernetes. It has a concept known as charts, used to define
what services are required, what images are used, and default settings when the run in the Kubernetes
cluster. It is used to push the Qlik Sense package into Kubernetes and relies on kubectl, so it must be
installed on the same machine as kubectl. Qlik uses helm to define a default chart to make deployments
simple for customers.
To install Helm on your local machine follow the instructions for your operating system at
https://docs.helm.sh/.
Before you begin you should have the following installed on your local machine:
l Kubectl
l Helm
1. Verify that kubectl is pointing to your Kubernetes cluster using the following command:
kubectl config current-context
2. If kubectl is not pointing to your Kubernetes cluster, use the following command to get a list of available
clusters:
kubectl config get-clusters
3. Set the kubectl to point to the desired cluster using the following command:
kubectl config set-cluster <cluster-name>
1. Run the following command to add Qlik’s helm chart repository to Helm. This is where Qlik Sense is
pulled from:
helm repo add qlik https://qlik.bintray.com/stable
2. Use the following command to get a list of all configured repositories and verify that the Qlik helm chart
repository was successfully added:
helm repo list
To use helm to with your Kubernetes cluster it needs to be initialized to create the helm Tiller pod that handles
installations:
2. If the Kubernetes cluster has security features such as RBAC enabled then the following commands
should be run in addition:
kubectl create serviceaccount --namespace kube-system tiller
kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --
serviceaccount=kube-system:tiller
l Set up a Kubernetes cluster and added a Storage Class with readwritemany storage
l Prepare your local tools to work with your Kubernetes cluster
The steps below cover the steps to install a first simple install. This includes deploying a test instance of MongoDB
and a simple IDP to get you running. To move it to a production ready state, you should review the additional
topics for the following areas:
Storing the configuration settings in a values.yaml allows you to reuse the settings in multiple deployments and
add new config sections simply. This can also be version controlled.
Use of a values.yaml file will be used predominately in the Qlik help. You can find more information about YAML
files online on sites such as ≤ https://en.wikipedia.org/wiki/YAML.
b. Add the following content to point the services requiring storage to the Kubernetes Storage Class,
update the name of the Storage Class as needed.
If you are using Kubernetes via Docker for Desktop or Minikube then you should not
add this section.
c. If you are using Minikube for test purposes, you should review and add the additional
configuration here: Using Minikube (page 24).
d. Save the file.
2. Qlik Sense will dynamically create engines to run scheduled reloads. To be able to do this, the engine
needs to be configured in Kubernetes as a custom resource.
This step only needs to be done once for a cluster. Run the following command to install custom resource
definitions used by dynamic engines:
helm install --name qliksense-init qlik/qliksense-init
3. The next step is to install the Qlik Sense package. Run the following command:
helm install -n qliksense qlik/qliksense -f values.yaml
The software now starts deploying to the Kubernetes cluster, including downloading all the images and
running them.
4. You can now use kubectl to check the progress. Run the following command:
kubectl get pods
If your deployment was successful you will see something similar to this:
NAME READY STATUS RESTARTS AGE
qliksense-collections-7f456595b8-vjhtf 1/1 Running 0 2m
qliksense-edge-auth-858f89b849-42z66 2/2 Running 0 2m
… (lines removed for brevity)
If services do not start check the log files of the service for more information. If some services
remain in a pending state, check that the Kubernetes cluster has readwritemany storage
available as a storage class and that is it correctly referenced in the YAML.
For most cloud vendors (for example AWS, GCP or Azure) the IP address will be generated during the installation
automatically. You can find the address by running the following command:
This step is only required when running a basic example, a production example will use a real Identity Provider
during which the correct DNS entry for the cluster will be used.
The simple IdP is for test purposes only and you should configure a full IdP by reviewing Setting up
identity providers (page 28).
You should now navigate to https://elastic.example/console to apply the license before being able to create
applications.
Minikube does not support the LoadBalancer resource that all other Kubernetes providers use and requires
running on a different port, an additional configuration section is required when using it.
These additional configuration items should not be used with any other Kubernetes provider as they
will not work.
Preparing Minikube
Before you start, review the installation documentation for Minikube for your operating system
here: https://kubernetes.io/docs/setup/minikube/.
When you start Minikube, ensure that it has enough resources by running the following (you may need to run
minikube delete first):
elastic-infra:
nginx-ingress:
controller:
service:
type: NodePort
nodePorts:
https: 32443
extraArgs.report-node-internal-ip-address: ""
hub:
ingress:
annotations:
nginx.ingress.kubernetes.io/auth-signin: https://$host:32443/login?returnto=$request_uri
management-console:
ingress:
annotations:
nginx.ingress.kubernetes.io/auth-signin: https://$host:32443/login?returnto=$request_uri
edge-auth:
oidc:
redirectUri: https://elastic.example:32443/login/callback
minikube ip
When using Minikube you must specify the port 32443 in the URLs used to access the product IP, for
example https://elastic.example:32443.
Once you have set up your Kubernetes cluster and prepared your local tools, you are ready to install Qlik Sense
Enterprise into your Kubernetes cluster. See Installing Qlik Sense Enterprise on Kubernetes (page 22).
Qlik supports deployments of Qlik Sense Enterprise on Kubernetes to Red Hat OpenShift platforms,
however the deployment is not currently certified by Red Hat.
Using MiniShift
To get an OpenShift platform running use MiniShift to create a virtual machine (VM) and provision a local,
single-node OpenShift cluster in the VM. RedHat provides MiniShift as a simple to run OpenShift platform.
MiniShift is available at https://github.com/minishift/minishift .
7. Create a new project. A project is the OpenShift equivalent of a kubernetes namespace.
Note that in this example we use oc instead of kubectl. In most cases they do the same thing,
however oc does some things that cannot be done with kubectl.
oc new-project tiller
10. Installing tiller on OpenShift requires a special process. OpenShift provides a yaml file to do that. Run the
following command:
oc process -f https://github.com/openshift/origin/raw/master/examples/helm/tiller-
template.yaml -p TILLER_NAMESPACE="$Env:TILLER_NAMESPACE" -p HELM_VERSION=v2.9.1 | oc create -
f -
12. Create a project for the Qlik deployment using the following command:
oc new-project qlik
13. To configure security you must log in as a system admin using the following command:
oc login -u system:admin
14. Configure the security settings needed by running the following commands:
oc policy add-role-to-user edit "system:serviceaccount:$($Env:TILLER_NAMESPACE):tiller"
oc policy add-role-to-user cluster-admin "system:serviceaccount:$($Env:TILLER_
NAMESPACE):tiller"
oc adm policy add-scc-to-user anyuid "system:serviceaccount:$($Env:TILLER_NAMESPACE):tiller"
oc adm policy add-cluster-role-to-user cluster-admin "system:serviceaccount:$($Env:TILLER_
NAMESPACE):tiller"
oc adm policy add-scc-to-group anyuid system:authenticated
oc adm policy add-scc-to-user privileged "system:serviceaccount:$($Env:TILLER_
NAMESPACE):tiller"
oc adm policy add-scc-to-user privileged system:serviceaccount:qlik:default
oc adm policy add-role-to-user admin system:serviceaccount:qlik:default
15. Define the storage and make it writable using the following command:
minishift ssh -- "sudo chmod -R o+rwx /var/lib/minishift/base/openshift.local.pv*"
17. Add the Qlik helm repository and update it using the following commands:
helm repo add qlik https://qlik.bintray.com/stable
helm repo update
18. You can now deploy Qlik Sense Enterprise on Kubernetes using the minishift.yaml file.
helm upgrade --install qsefe qlik/qsefe --set devMode.enabled=true,engine.acceptEULA="yes" -f
C:\dev\minishift.yaml
19. To monitor deployments you can run kubectl get pods, or oc get pods.
An implementation of Qlik Sense Enterprise on Kubernetes can vary depending on the configuration required.
The following pages detail on the key elements required to do a production implementation:
When you install Qlik Sense Enterprise on Kubernetes, we provide a default set of service keys for
service to service communication. We recommend that you rotate these default keys as part of
securing your install for production.
1. Create a Deployment in the Multi-cloud Setup Console on your Qlik Sense Enterprise on Windows
deployment.
See Multi-Cloud Setup Console - start page and MSC - Deployments.
2. Create a distribution policy to decide which applications should be distributed.
See Distribution policies - introduction.
3. Publish the application setting the collection, userswithaccess or groupswithaccess properties on the
app.
See Publishing apps to cloud hub collections.
Once you have distributed the apps, you will be able to open them from the hub.
repeatedly. In contrast to on-premise technologies, such as Active Directory and LDAP, identity providers also
offer a consistent and governed experience when accessing cloud services, eliminating the need to create
accounts for each new service.
If user accounts are stored in Active Directory, the IdP can still enable integration into cloud
software.
In Qlik Sense Enterprise on Cloud Services, Qlik Sense Enterprise on Kubernetes or in a multi-cloud deployment,
an IdP delivers the following:
l Secure authentication of a user and a common identity (user ID and groups) passed between all
deployments.
l Common user identity to assign a license to (to avoid double use).
l Common user ID and attributes, such as groups, to use when applying access control to content.
IdP requirements
Both Qlik Cloud Services and Qlik Sense Enterprise on Kubernetes integrate with an IdP using the OpenID
Connect (OIDC) standard. This is a standard that allows both interactive login, where a user logs in via a
browser, and automated login, using APIs via a software product.
Qlik Sense Enterprise on Windows currently does not support OIDC, but supports SAML, or any method that
allows a consistent user identity to the one provided by the IdP.
In summary, an IdP for multi-cloud must support both OIDC and SAML.
The following is required from the IdP to be able to set up Qlik Sense Enterprise on Kubernetes to use it:
l discoveryUrl: the OpenID Connect Discovery URL which allows applications, such as Qlik Sense, to use
the IdP with minimal configuration.
l clientId: uniquely identifies the client from the IdP.
l clientSecret: the secret that the client uses along with the client ID to authentication with the IdP.
l realm: the name to associate with the IdP.
l hostname: the hostname that is used for the deployment of Qlik Sense Enterprise on Kubernetes.
These values are added to the values.yaml file under the identity-providers section when installing Qlik Sense
Enterprise on Kubernetes.
Step-by-step examples of this configuration are provided for the following IdP vendors:
l Okta
See Setting up Okta .
l Auth0
See Setting up Auth0.
l ADFS
See Setting up ADFS.
Setting up ADFS
ADFS is an authentication and authorization platform.
You can configure ADFS as an identity provider (IdP) for use with Qlik Sense Enterprise on Kubernetes (QSEoK)
and Qlik Sense Enterprise on Windows (QSEfW). You will create an application group, a server application, and a
Web API to be used for interactive login (QSEoK). You will also map claims from Active Directory to the ID token.
The following procedures are examples using ADFS 10. Please review the ADFS documentation for
more information and latest instructions.
Example: https://adfs.elastic.example/1234567890.
7. For Redirect URI, set the redirect URL to the login callback for the tenant in the format
https://<host>/login/callback/ .
Example: https://adfs.elastic.example/login/callback
8. Optionally, enter a description.
9. Click Next.
The Configure Application Credentials page is opened.
10. Select Generate a shared secret. Note down this secret, you will not have access to it again. You will
use it as client secret.
11. Finish the wizard.
Do the following:
1. Open the application group to edit the web API you created. Open the Issuance Transform Rules tab.
2. Create a rule from the rule template Send LDAP Attributes as Claims.
3. Select Active Directory as the attribute store.
4. Add claims mappings. You may need to type the outgoing claim.
5. Map Token-Groups - Unqualified Names to groups.
6. Map Display-Name to display_name.
7. Finish the claims mapping.
l ADFS installation
l the required resources configured in ADFS
l Configuration settings from your ADFS application: discoveryUrl, clientId, and clientSecret
l The following values from your hybrid deployer: public key, key ID, and issuer.
Many of the code examples contain placeholder values that need to be replaced by your own values.
You provide configuration to Qlik Sense Enterprise on Kubernetes by using a values.yml file. The values.yml file
should look like the following example:
devMode:
enabled: true
engine:
acceptEULA: "yes"
identity-providers:
secrets:
idpConfigs:
- discoveryUrl: "https://adfs-host/adfs/.well-known/openid-configuration"
clientId: "https://adfs.elastic.example/1234567890"
clientSecret: "<client secret>"
realm: "ADFS"
hostname: "adfs.elastic.example"
useClaimsFromIdToken: true
claimsMapping:
sub: ["sub", "appid"]
client_id: "appid"
name: "display_name"
- issuerConfig:
issuer: https://the-issuer
primary: false
realm: "ADFS"
hostname: "adfs.elastic.example"
staticKeys:
- kid: "thekid"
pem: |-
-----BEGIN PUBLIC KEY-----
MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEsMSxQjXxrvqoKSAREQXsr5Q7+/aetjEb
OUHt8/Cf73WD56cb4QbHthALl5Ej4MUFOAL9imDmVQe58o9b1j5Zo16Rt1gjLDvd
nqstc+PX4tyxqGadItJAOU3jka7jYghA
-----END PUBLIC KEY-----
It is important to note that the userClaimsFromIdToken flag is set to true. The flag instructs edge-
auth to use the claims from the ID token instead of querying for userinfo. This is because ADFS
returns very little in the userinfo response and instead includes most information in the ID token.
You will have to insert your own values for discoveryUrl, clientId, clientSecret, realm and hostname.
$ helm upgrade \
--install \
qliksense qlik/qliksense \
-f values.yml
To make sure that your configuration has been applied, you can run the get values command to see the
resolved configuration:
devMode:
enabled: true
engine:
acceptEULA: "yes"
identity-providers:
secrets:
idpConfigs:
- discoveryUrl: "https://adfs-host/adfs/.well-known/openid-configuration"
clientId: "https://adfs.elastic.example/1234567890"
clientSecret: "<client secret>"
realm: "ADFS"
hostname: "adfs.elastic.example"
useClaimsFromIdToken: true
claimsMapping:
sub: ["sub", "appid"]
client_id: "appid"
name: "display_name"
- issuerConfig:
issuer: https://the-issuer
primary: false
realm: "ADFS"
hostname: "adfs.elastic.example"
staticKeys:
- kid: "thekid"
pem: |-
-----BEGIN PUBLIC KEY-----
MHYwEAYHKoZIzj0CAQYFK4EEACIDYgAEsMSxQjXxrvqoKSAREQXsr5Q7+/aetjEb
OUHt8/Cf73WD56cb4QbHthALl5Ej4MUFOAL9imDmVQe58o9b1j5Zo16Rt1gjLDvd
nqstc+PX4tyxqGadItJAOU3jka7jYghA
-----END PUBLIC KEY-----
In order for <hostname> to resolve, add the following to your /etc/hosts file:
127.0.0.1 <hostname>
::1 <hostname>
Setting up Auth0
Auth0 is an authentication and authorization platform.
You can configure Auth0 as an identity provider (IdP) for use with Qlik Sense Enterprise on Kubernetes (QSEoK)
and Qlik Sense Enterprise on Windows (QSEfW).
Creating an Auth0 application and connection for QCS or QSEoK for interactive
logins
Create an Auth0 application, and connect it to an Auth0 database connection.
An Auth0 application allows an application, (QSEfW/QCS/QSEoK), to use Auth0 for authentication. An Auth0
connection is a source of users, in this example, a database that you populate with users.
The following procedures are examples. Please review the Auth0 documentation for more
information and latest instructions.
Do the following:
You set up programmatic access so that you can distribute content into Qlik Cloud Services (QCS) or QSEoK.
In Auth0, you will create a new API. In this case, the Auth0 API represents the protected QSEoK resource API. In
OAuth terms, you configure Auth0 for the Client Credentials Grant flow.
Do the following:
Just like you created an Auth0 application for interactive logins above, you will now create an Auth0 application
for programmatic authentication.
Do the following:
l Auth0 account
l Auth0 tenant
l Auth0 app, configured with interactive login and programmatic access
l Configuration settings from your Auth0 application: discoveryUrl, clientId, and clientSecret
Many of the code examples contain placeholder values that need to be replaced by your own values.
You provide configuration to QSEoK by using a values.yml file. The values.yml file should look like the following
example:
devMode:
enabled: true
engine:
acceptEULA: "yes"
identity-providers:
secrets:
idpConfigs:
- discoveryUrl: "<OpenID Configuration from Application>"
clientId: "<Client ID from Application>"
clientSecret : "<Client Secret from Application>"
realm: "<Name for this IdP>"
hostname: "<Hostname for your QSEoK tenant>"
claimsMapping:
client_id: [ "client_id", "<id>" ]
You need to enter the values for discoveryUrl, clientId, clientSecret, realm, hostname, and id (claims mapping).
$ helm upgrade \
--install \
qliksense qlik/qliksense \
-f values.yml
To make sure that your configuration has been applied, you can run the get values command to see the
resolved configuration:
devMode:
enabled: true
engine:
acceptEULA: "yes"
identity-providers:
secrets:
idpConfigs:
- discoveryUrl: "https://tenant.auth0.com/.well-known/openid-configuration"
clientId: "<client ID>"
clientSecret : "<client secret>"
realm: "Auth0"
hostname: "<hostname>"
In order for <hostname> to resolve, add the following to your /etc/hosts file:
127.0.0.1 <hostname>
::1 <hostname>
Setting up Okta
Okta is an authentication and authorization platform.
This topic presents how to set up Okta to be used with Qlik Sense Enterprise on Kubernetes (QSEoK) and Qlik
Sense Enterprise on Windows (QSEfW). You can configure Okta as an identity provider (IdP) for use with QSEoK
and QSEfW.
Creating an Okta application and user for QSEoK for interactive logins
Create an Okta application and a user. An Okta application allows an application, (QSEfW/Qlik Cloud Services
(QCS)/QSEoK), to use Okta for authentication.
When you install Qlik Sense Enterprise on Windows, with Multi-Cloud, you must use a developer
account for Okta, see ≤ Okta Developer.
Creating a user
Create a user in Okta. You can skip this step if you have already created users.
Do the following:
Do the following:
This is the IP address or server name from your QSEoK. Example: https://40.118.9.61
Creating an Okta API resource server and application for programmatic access
In Okta, you create a new Resource Server API. In this case, the Okta Resource Server API represents the
protected QSEoK resource API. In OAuth terms, you need to configure Okta for the Client Credentials Grant flow.
First, create a new Authorization Server (under the API tab) for your tenant.
Do the following:
Do the following:
After completing the steps, you will be able to log into a QSEoK tenant using an Okta user name and password
as well as interact with the QSEoK tenant programmatically.
We assume that you are running QSEoK on a Mac which has Kubernetes running using Docker for Mac. Also
without this exact configuration, you should be able to use the same concepts if running Kubernetes in other
supported ways.
l Okta account
l Okta tenant
l Okta app, configured with interactive login and programmatic access.
l Configuration settings from your Okta application:
l discoveryUrl: The OpenID Connect Discovery URL which allows applications, such as QSEoK, to
use Okta with minimal configuration.
l clientId: Uniquely identifies the client that is using Okta for authentication.
l clientSecret: Secret that the client uses along with the Client ID to use Okta for authentication.
Many of the code examples contain placeholder values that need to be replaced by your own values.
You provide configuration to QSEoK by using a values.yml file. The values.yml file should look like the following
example:
devMode:
enabled: true
engine:
acceptEULA: "yes"
identity-providers:
secrets:
idpConfigs:
- discoveryUrl: "<OpenID Configuration from Application>"
clientId: "<Client ID from Application>"
clientSecret : "<Client Secret from Application>"
realm: "<Name for this IdP>"
hostname: "<Hostname for your QSEoK tenant>"
You need to enter the values for discoveryUrl, clientId, clientSecret, realm, and hostname.
In Okta, you can find your Client ID and Client secret under the General tab in the Client Credentials section
for the application you created.
127.0.0.1 <hostname>
::1 <hostname>
devMode:
enabled: true
engine:
acceptEULA: "yes"
identity-providers:
secrets:
idpConfigs:
- discoveryUrl: "https://dev-<tenantid>.oktapreview.com/.well-known/openid-configuration"
Use Helm to apply the configuration in your values.yml file to your Kubernetes cluster:
In this example, the certificate is in a file called tls.crt and the associated private key is in a file called
tls.key.
1. Create a file called secret.yaml which will hold the certificate and its key. See the yaml definition below
for an example:
apiVersion: v1
kind: Secret
metadata:
name: my-certificate
namespace: default
type: kubernetes.io/tls
data:
tls.crt: |
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUdvekNDQll1Z0F3SUJBZ0lRQXQzWkZQUk5W
VWREZ3NCTDNPZnZUREFOQmdrcWhraUc5dzBCQVFzRkFEQk4KTVFzd0NRWURWUVFHRXdKVlV6RVZN
...
b0hNbTJ2dmhyb1pRU1g1S1FZUmNDYgptaEpSSFAraWlwMWFUblJOaGhOMytJa2tvYm1DVEhnPQot
LS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
tls.key: |
LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb2dJQkFBS0NBUUVBeUJiT1FxNTdM
SlNibEhESkx3R1ZWM3Avb1hjZ0FXTElUalV6Smd6Mmc2MGJzV1loCmtLbmNwcEJtWWpQWVJtZHJC
...
YnJPRCtCNkNieXRtaEovblJ5dW9SODJmRVp3MW1DTGZyZ2lUZlZ4SHZBT0c0QVU9Ci0tLS0tRU5E
IFJTQSBQUklWQVRFIEtFWS0tLS0tCg==
2. You can give the name field a meaningful name. In this example we've use my-certificate.
The tls.crt field is the base64 encoded value of your certificate. You can get this value using the following
command:
$ cat tls.crt | base64
3. The base64 decoded value will be displayed on the screen. Enter it for the tls.crt value in your .yaml file.
4. Do the same for the tls.key:
$ cat tls.key | base64
7. You can verify the secret has been created using the following command:
$ kubectl get secret my-certificate
1. Configure the Qlik Sense ingress to use the secret created in the previous procedure by adding the
following to your values.yaml file:
# References the “my-certificate” secret created within the “default” namespace
elastic-infra:
nginx-ingress:
controller:
extraArgs:
default-ssl-certificate: "default/my-certificate"
By default, a pre-configured MongoDB Community Edition is added during the installation of Qlik Sense
Enterprise on Kubernetes (QSEoK). This is only intended to be used for quick start, testing and evaluation
purposes. If you use this version, your MongoDB data may be lost if the Kubernetes cluster is updated.
Example:
helm upgrade \
--install qliksense qlik/qliksense \
--set mongodb.uri=<your-connection-string>,engine.acceptEULA="yes"
The connection string format will vary depending on the configuration used. This format will be different if using
a Kubernetes secret to connect with.
mongodb://user:password@mongodbhost:port/databasename
Some services assume that SSL is enabled in MongoDB. If SSL is not being used then add
`?ssl=false` to end of the connection URI.
Referencing values.yaml
Create the values.yaml file and include the settings you want to reference in the helm install command.
Example: values.yaml
engine:
acceptEULA: "yes"
devMode:
enabled: false
mongodb:
uri: "<your-connection-string>"
identity-providers:
secrets:
idpConfigs:
- <your IdP configuration here>
The values.yaml file is then referenced in the helm install command:
helm upgrade \
--install qliksense qlik/qliksense \
-f values.yaml
The Qlik License Service is included in Qlik Sense Enterprise February 2019 and later releases and is used when
Qlik Sense is activated using a signed key license. The Qlik License Service stores the information about the
license, and communicates with a License Back-end Service, hosted by Qlik, for product activations and
entitlement management. Port 443 is used for accessing the License Back-end Service and retrieving license
information.
With Qlik Sense June 2019 or later you can configure the communication between Qlik License service and the
Qlik License Back-end to be handled by a proxy.
In Qlik Sense Enterprise on Kubernetes, configuration of a proxy for the Qlik License Service is done using helm
configurations. Both HTTP and HTTPS scheme are supported.
Add the following content in the values.yaml file under the Licenses section:
## Proxy configuration
## Set the following values when deploying behind a proxy
proxy:
## The URI to the tunneling proxy scheme://host:port (e.g. http://proxy.company.com:8888)
uri: