When making outbound HTTP requests, most times we’ll use some sort of secret API key that’s specific to our app and we get billed by request to authenticate to the external service.
To that end, we need to able to store them securely on the subnets. With the current state of things, node operators with physical access to the node machines can access all data stored on the subnet they are a part of.
This request is primarily for storing sensitive keys and providing basic management like retrieval, rotation, access control, etc. for them.
Most cloud providers have a service that performs this. AWS has this and Google Cloud has this. So do other cloud providers.
For making any authenticated outbound requests, this feature is an absolute requisite.
Unfortunately, the HTTPS outcalls feature in its current form should not be used for such authenticated requests, for the reasons you mentioned.
This is something I have been thinking about for some time now. It is not very easy to do as even if we have such secure storage, the eventual request still goes out from each of the nodes in a subnet, so all of them can see the HTTP headers and the “secret” key. Unlike on AWS and Google, we do not want to trust any single infrastructure provider. So it would mean we cannot expose the content of the request to any node on the subnet.
The only viable way I see for this issue is to use trusted execution, such as SEV-SNP, but this also means you should trust the TEE provider (e.g., AMD).
You could have a different kind of subnet that are dedicated for storage and processing of secret information. And they are exclusively constituted of nodes capable of providing TEEs.
Naturally, cycle costs on these would differ from a normal application subnet.
But I believe you are already doing exclusive subnets for the upcoming SNS feature.
And this should open up more avenues for further kinds of specialized subnets with specialized hardware like:
GPU subnets for running workloads that require GPUs like machine learning
low cost storage subnets with high storage and low compute/memory and reduced replication
quantum computers(?)
But yeah, for now, being able to securely store and transmit secrets is a basic need.