What is this?
This is a collection of systems that are accidentally key-value stores. These systems are not designed to be key-value stores, but they can be coerced into being one. Contribute on GitHub.
Prerequisites
To be included in this list, a system must meet the following criteria:
- It must not be designed to be a key-value store.
- It must implement
GET,SETandDELoperations, or similar. - It must be reachable over the network, or otherwise accessible.
- It must be possible to store relatively arbitrary data in it.
Systems
XDP (Express Data Path)
How?
This absolutely cursed thing comes from B Horn. “We can use [XDP] to implement a terrible Key-Value store that can be queried over the network by seeing if it drops a TCP connection. By sending a guess, the eBPF code can check if its greater than the real value and drop the connection if that is the case. This lets us perform a binary search to discover the value!”
Limits
The limit is your sanity.
Slack
How?
Slack messages can contain attachments. These attachments can contain fields that can be used to store configuration data. Message bodies can also be used.
Limits
Heroku Config Variables
How?
Heroku provides a way to store configuration variables in the environment. These variables are accessible to your application and can be used to store sensitive information like API keys and passwords. No additional charge.
Limits
100 apps * 64 kb = 6.4 MB of storage. Source.
DNS
How?
Arbitrary data can be stored in DNS TXT records. This is a common way to store configuration data for services that are accessed via DNS.
Limits
255 bytes per TXT record.
However many records you feel comfortable with in a zone file.
AWS Resource Tags
How?
AWS resources can be tagged with key-value pairs. These tags can be used to store configuration data for the resource.
Limits
50 tags per resource. 128 characters per key, 256 characters per value. ~19 KB of data per tag set.
GitHub Gists
How?
Gists can be used to store configuration data. They can be public or private.
Limits
Unable to find any solid documented limits on Gists.
GitHub Actions Variables
How?
GitHub Actions can store configuration data in variables. Unlike secrets (which can’t be read back out), variables can.
Limits
Limits are documented. You can store up to 1,000 organization variables, 500 variables per repository, and 100 variables per environment. The total combined size limit for organization and repository variables is 256 KB per workflow run.
Bluesky
How?
Bluesky has a robust API for creating posts and reading them back. This can be leveraged similar to the Turla malware group.
Limits
Rate limits are documented, on top of service limits.
Kubernetes Annotations
How?
Kubernetes objects can be annotated with key-value pairs. These annotations can be used to store configuration data.
Limits
Syntax for keys is documented. Total size limit is 256 KiB.
Stripe Metadata
How?
Stripe objects can be annotated with key-value pairs. Metadata can be used to do horrible things, like store application state(!).
Limits
50 keys per object. 40 characters per key, 500 characters per value.
AWS S3
How?
Kind of cheating as S3 is “malloc for the internet”, but S3 is an extremely viable key-value store even if the intention is to store “objects”.
Can be paired with the tagging system above to have 0 byte objects with tags as the “real” storage.
Limits
Well documented, plus costs of API calls.