I wanted some of the variable defined in ICP , how to use .env in ICP ?
This worked for me (in a backend Rust canister):
- Create a
.env
file in the root of the project repository. For example, let’s say your .env file looks like this:
MAIL_API_KEY='dddddddddd'
POSTMAN_API_KEY='aaaaaaaaaa'
- You must then export the entire
.env
file by running these commands:
set -a
source .env
set +a
- When you need to call the environment variable in your Rust canister, in this format: option_env!
("name_of_the_environment_variable")
.
Using the .env file above as an example:
option_env!("MAIL_API_KEY")
@jennifertran how is that secure? Are the env vars exposed?
The canister state is private to a certain degree (for example, a user who is not a canister controller cannot inspect a private function). However, there is technically a risk of malicious subnet nodes inspecting the canister state.
when i run dfx deploy backend –network ic
the env will be uploaded as well, or should I run the another command again for ic?
What exactly do you mean by “upload”? As far as I can tell, the option_env!
should make it so that the env variable value is part of the WASM, and WASM is more or less private as stated above.
If you want to store API keys in a secure way look into vetkeys, it’s a new feature
I’m not an expert in VetKeys, but I understand they don’t address the use case of “saving API keys in/for your backend”. If they do, I’d be really curious to learn how because that sounds interesting?
Vetkeys do not solve the problem in this case. As far as I know, with vetkeys a canister cannot encrypt and decrypt keys.
They are designed to be used by external principals like identities. The encryption/decryption is actually done on the client side once you have a ecdsa public key