Secrets & encryption
This section details the encryption options in Qlik Cloud and highlights some common secret management activities.
Encryption
Every tenant in Qlik Cloud has multiple layers of security to protect your data. While you can safely rely on the default, out-of-the box configuration, you can opt to provide your own encryption key if you have specific requirements, such as HIPAA.
Learn more about tenant encryption or discover how to configure tenant encryption.
Secret management
Everything in the modern web relies on secrets. Qlik Cloud is no different and accepts various secret types across services. To help you assess how to manage these secrets to comply with rotation and offboarding processes, the following table outlines the most commonly leveraged services, their secret types, and the update approach.
| Qlik Cloud service | Usage | Common secrets | Management approach |
|---|---|---|---|
| Analytics data connections | Loading and storing data using Qlik Sense applications | Various | Can be updated using the Data Connections API, with the exception of data connections leveraging interactive OAuth authentication. See more at update data connections |
| API keys | Connecting to legacy backend systems which don’t yet support OAuth M2M clients | Bearer token | API keys can be generated using the API Keys API |
| Automations (triggered) | Automations can be triggered using an execution token | Execution token | Automations can be duplicated using the Automations API |
| Automations connections | Connecting to your data sources in Qlik Application Automation workflows | Various | Connections can be updated using the Automation Connections API |
| OAuth clients | Connecting Qlik Cloud to any third-party systems, and for orchestration of deployments | Client ID and secret | Secrets can be regenerated using the OAuth Clients API |
| Tenant email | Sending tenant-wide notifications, alerts, and subscriptions | Username and password | Can be updated using the Transports API |
Regardless of whether your organization enforces secret rotation on a schedule, you should have a approach for updating secrets across your tenants.
Secret rotation for Qlik Cloud services
For secrets that are generated and maintained by Qlik Cloud, you can manage rotation with your own scripts or Qlik Application Automation. The approach varies slightly for each secret type.
API keys
API keys are per-user tokens with a fixed expiry time set upon creation. They can’t be extended and don’t support custom scopes, instead acting with the permissions of the owner.
To rotate, your tooling should create a new API key, cut services across, and then delete the old key (or let it expire). This can be done using the user interface or the API keys API.
API keys are usually used for observability by the monitoring apps, as the REST connector in Qlik Sense doesn’t support OAuth. Where possible, use OAuth clients for programmatic auth.
OAuth clients
OAuth clients come in several types. Only confidential clients (machine-to-machine) OAuth clients provide a client secret which may need to be rotated. These secrets do not expire.
It is possible to create multiple secrets for a single OAuth client, so to rotate, create a new secret, cut services across, and then delete the old secret. This can be done using the user interface or the OAuth clients API.
Execution tokens for triggered Automations
Triggered runs of Qlik Application Automation expose automations via a REST endpoint. When enabled, an execution token unique to that automation is generated. This token does not expire.
To change the execution token, you must duplicate the automation, and remove the original automation. This can be done using the user interface or the Automations API.
Next steps
Move onto the next section, or go back to the playbook introduction.