Secure Tenancy is planned to be End-of-Life at the end of 2022 in favor of built-in security enhancements. Existing customers using Secure Tenancy will continue to be supported on Honeycomb Classic until this time.
This topic describes the features, options, installation, and configuration of Honeycomb Secure Tenancy, also referred to as Secure Proxy. If you have questions or need assistance with any aspect of installing or configuring this functionality, contact your Honeycomb representative for help.
Secure Tenancy provides a mechanism to allow nearly all of Honeycomb’s functionality while ensuring that no plaintext strings ever leave your private infrastructure. It accomplishes this by encrypting data before it is ingested by Honeycomb, and then decrypting it when it is viewed within your network.
Both options make use of a Honeycomb Secure Proxy running in your infrastructure. No plaintext data ever traverses Honeycomb’s infrastructure and the Honeycomb UI presents complete transparency to authorized members of your team. You have complete control of key rotation and reissuance down to the columnar level from within your own infrastructure.
In either case, unmasked data cannot end up in a Honeycomb dataset, even accidentally. Data is inspected upon ingestion for Secure Tenancy teams, and any event or metric containing unmasked data is rejected before being stored.
With Data Encryption, all strings in your datasets are encrypted and the keys are stored in a database on the Secure Proxy running in your infrastructure. When an authorized user accesses Honeycomb, their web browser connects to the Secure Proxy directly and the data is unencrypted for them. Honeycomb infrastructure never has access to the sensitive data in plaintext.
Data Encryption is implemented using industry-standard AES 256-bit encryption.
With Data Hashing, all individual strings in your datasets are hashed and the hash mappings are stored in a database on the Secure Proxy running in your infrastructure. When an authorized user accesses Honeycomb, their browser sends the hashed data to the Secure Proxy running in your environment and receives the un-hashed data back. Again, no plaintext sensitive data reaches the Honeycomb infrastructure.
Data Hashing is implemented using industry-standard SHA-256 hashing.
With Data Encryption, your Secure Proxy database instance stores the unique keys that are used to encrypt the strings sent to Honeycomb. The database size is proportional to the number of individual columns in your datasets, but does not vary with the amount of data transferred.
With Data Hashing, the Secure Proxy database instance stores the hash code and value of every unique string sent in your data. The database size and traffic is proportional to the number of unique string values in your datasets. This is likely to require a significantly larger and more performant database implementation.
With Data Encryption, it is theoretically possible that an attacker, with enough compute power, could decrypt the data stored by Honeycomb. With Data Hashing, this is not even theoretically possible, but normally, it will be significantly more expensive to operate and manage. Most customers choose to use Data Encryption.
All string values sent as part of your events or metrics are masked when you use Secure Tenancy. Additionally, most metadata strings are masked, such as column names, descriptions, derived column aliases, board names, board descriptions, and query captions.
The following strings are sent to third party services for notifications and will not be masked by the secure proxy:
Please only use names and descriptions that you feel comfortable storing in Honeycomb’s database and sending through third parties such as Slack or PagerDuty.
Did you find what you were looking for?