re: I was billed for 14k USD on Amazon Web Services 😱 VIEW POST

VIEW FULL DISCUSSION
 

few more ideas:

Never put your api keys in repos. period. (public or private).

Put them in environment variables but keep them completely separate from the source code repo. like development.env, production.env.

Always follow the practice of least privilege. Even most engineers at a company should only need
development.env variables if they are just writing code and not doing production support.

production.env should be guarded with only very few people that must have access to production system.

 

I had the impression KMS is the way to go here.

Put the encrypted keys in the repo and decrypt them before usage.

 

I do not think that this is a good idea. You would put encrypted keys and the decryption algorithm in the repo. It is still possible to get to the keys.

Well encrypt it and decrpyt it with your private key.

hash_hmac :)

First of all: The named function hash_hmac does not encrypt. It creates a hash, which cannot be used to restore the original value. It is one way.

If you would use a proper encryption the logic is still faulty.

You have a secret, that cannot be added plainly to the repository. You add some decryption logic, encrypt the original secret and add it to the repository. The original secret is now safe. But now you have another secret (the private key needed for decryption) that cannot be added plainly to the repository.

You still have the same situation plus some extra decryption code, which has to be maintained. Also your build process has to handle the encryption.

code of conduct - report abuse