How to Implement Data Encryption in Looker
Securing your data in Looker is about more than just setting user permissions, it's about protecting the data itself, especially within Looker’s internal database where sensitive information like connection credentials and user details are stored. This article will guide you through the essential methods for implementing data encryption in your Looker instance, from the standard legacy approach to using advanced customer-managed keys in the cloud.
Why Encryption in Looker Matters
When we talk about data security in a business intelligence tool, there are two primary areas of concern: data in transit and data at rest. Data in transit is typically secured using standard TLS/SSL protocols, which encrypt the communication between your browser and the Looker server, and between Looker and your database. While crucial, this is a standard and often straightforward setup.
The more complex challenge is securing data at rest. Looker uses an internal database (HyperSQL by default, but often a backend MySQL DB for larger instances) to store a wealth of critical information, including:
- Configurations and settings for your Looker instance.
- Usernames and sensitive authentication information.
- Credentials for your database connections.
- Cached query results.
- History of queries run by users.
If this internal database is compromised, an attacker could gain access to everything they need to connect to your primary analytics databases. Encrypting this data at rest adds a powerful layer of defense, making the raw information unreadable even if the underlying server is breached.
Setting Up Legacy AES-256 GCM Encryption
For customer-hosted or private cloud Looker installations, the original method of encryption is using a local AES-256 GCM key. It’s a robust and reliable way to secure your instance. The process involves generating a key, storing it in a file, and telling Looker where to find it.
Free PDF · the crash course
AI Agents for Marketing Crash Course
Learn how to deploy AI marketing agents across your go-to-market — the best tools, prompts, and workflows to turn your data into autonomous execution without writing code.
1. Generate Your Encryption Key
First, you need a 32-byte (256-bit) encryption key. The easiest way to create a strong, random key is using a command-line tool like OpenSSL. Open your terminal and run the following command:
openssl rand -base64 32This command will output a unique, base64-encoded string that will serve as your master key. It will look something like this: fJk0s/aB4E+lG3CzPn8qRv7xT/s2mD7bU9cWzV4yL8w=.
Extremely important: Treat this key like a password to your entire Looker instance. Store it in a secure location like AWS Secrets Manager, HashiCorp Vault, or your company's designated password manager. Do not save it in a plain text file on your desktop, email it, or commit it to a Git repository.
2. Create a Key File on Your Looker Server
Once you have your key, you need to save it to a file on the same server where Looker is installed. By convention, this file is named lkr.key.
- Create the file in your Looker directory (e.g.,
/home/looker/). - Paste the key you generated into this file and nothing else - no extra spaces or new lines.
After creating the file, you must set its permissions so that only the user running the Looker process can read it. This prevents other users on the server from accessing your key.
chmod 600 lkr.key3. Set the Environment Variable
Next, you need to tell Looker where to find this key file. You do this by setting an environment variable called LKR_MASTER_KEY_FILE that points to the absolute path of your key file.
export LKR_MASTER_KEY_FILE=/home/looker/lkr.keyFor this setting to persist every time Looker restarts, you should add this export command to your Looker startup script (looker.sh) or a separate environment file (.env or similar) that gets loaded before Looker starts.
4. Start Looker and Verify
With the key file in place and the environment variable set, start (or restart) your Looker instance. During its boot process, Looker will:
- Check for the
LKR_MASTER_KEY_FILEvariable. - Read the key from the specified file.
- Use the key to encrypt the sensitive parts of its internal database.
One critical takeaway: this process is effectively a one-way street. Once the database is encrypted, Looker will require this exact key file to start up every single time. If you lose the key, you will permanently lose access to your Looker configuration. Back it up in a highly secure but recoverable location.
Advanced Encryption: Using Customer-Managed Keys (CMK)
If your Looker instance is hosted on AWS or Google Cloud, you can use a more advanced and flexible method: Customer-Managed Encryption Keys (CMK). This lets you use your cloud provider’s native Key Management Service (KMS) to control the encryption key.
The primary benefit of CMK is that you maintain full control over the key's lifecycle. You can manage access policies, set up a rotation schedule, and most importantly, revoke Looker's access to the key at any time. Revoking access effectively renders the Looker internal database inaccessible, giving you a powerful tool for controlling your data's security.
CMK on AWS: A High-Level Walkthrough
Setting up CMK involves creating a key in your AWS account and giving your Looker instance permission to use it. Here’s a summary of the steps:
1. Create a KMS Key in AWS
Navigate to the AWS Key Management Service (KMS) dashboard. From there, create a new symmetric KMS key. You’ll give it an alias (e.g., looker-cmk-key) and a description to identify it easily.
2. Grant Looker Permission to Use the Key
This is the most involved part of the process. Your Looker instance runs under a Google Cloud service account. To allow this account to use a key in your AWS account, you need to:
- Create an IAM policy in AWS that grants
kms:Encryptandkms:Decryptpermissions specifically for the KMS key you just created. - Create a new AWS IAM Role that trusts the Looker service account, allowing it to assume this role.
- Attach the permission policy to this new role.
This cross-cloud identity federation tells AWS to trust Looker and allow it to perform specific actions with your KMS key.
3. Configure Looker to Use Your AWS Key
Finally, you configure your Looker instance to use the key. This is typically done in the Google Cloud Console for your Looker instance settings, where you provide the Amazon Resource Name (ARN) of the KMS key. Once set, Looker will use this key for all future encryption operations.
CMK on Google Cloud
The process is similar and slightly simpler for Looker instances hosted on Google Cloud itself:
- Go to the Key Management section in the Google Cloud Console and create a new symmetric key within a key ring.
- Find your Looker instance's unique service account ID from its settings page.
- In IAM, grant that service account the "Cloud KMS CryptoKey Encrypter/Decrypter" role on the specific key you created.
- Update your Looker instance configuration with the full resource name of your new KMS key.
Don't Forget About Encrypting Database Connections
Encrypting Looker's internal database is vital, but so is encrypting the connection from Looker to your analytics database (like Redshift, Snowflake, or BigQuery). This ensures that no data is sent in plain text over the network.
Free PDF · the crash course
AI Agents for Marketing Crash Course
Learn how to deploy AI marketing agents across your go-to-market — the best tools, prompts, and workflows to turn your data into autonomous execution without writing code.
Enabling SSL/TLS for Your Connection
Most modern databases support an encrypted connection via SSL/TLS. Looker makes this easy to enable. When editing your database connection settings in the Admin panel:
- Look for a checkbox or toggle labeled "Verify SSL Cert."
- Enable this option.
For most cloud databases like BigQuery and Snowflake, whose SSL certificates are issued by publicly trusted Certificate Authorities, that's it. Looker will automatically establish a secure, encrypted connection.
Using a Custom or Self-Signed Certificate
If your database is hosted on-premise and uses a self-signed certificate, you’ll need to perform an extra step. You'll need to check the full SSL/TLS options in the database connection settings and provide the necessary certificate files to the Looker server so it can verify the database's identity. Always default to encrypting traffic unless your Looker instance and database are in an isolated, highly secure private network where you have complete control over traffic.
Final Thoughts
Properly securing a Looker instance requires a multi-layered approach. It starts with encrypting the internal metadata database using either a local key file for self-hosted instances or a more flexible Customer-Managed Key (CMK) in AWS or GCP. From there, it extends to ensuring all connections between Looker and your analytical databases are protected with TLS/SSL encryption.
While mastering Looker’s configuration is a valuable skill, managing the setup and security for traditional BI tools often comes with a steep learning curve and constant maintenance. We built Graphed to remove this technical overhead, as we handle the complexities of secure data connections for you. You just connect your sources in a few clicks, and our platform automates the heavy lifting so you can start asking questions in plain English and get back insightful, real-time dashboards in seconds, allowing you to focus on analyzing your data rather than managing infrastructure.
Related Articles
How to Create Facebook Ads API for Claude Code
Create a Meta Marketing API access token that never expires, using a system user, so Claude Code can pull Facebook ad reports and manage campaigns.
ClickHouse vs Postgres: When to Switch to Columnar
Comparing ClickHouse vs PostgreSQL means matching storage architecture to workload. Row storage wins for transactions. Columnar wins for scan-heavy analytics.
Google Ads for Orthodontists: Get More Booked Consults
Most orthodontic Google Ads campaigns waste money on low-intent searches. The problem is structure, not the platform.