Closed btcookies closed 2 years ago
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
This issue now has a funding of 350.0 ETH (1186436.52 USD @ $3389.82/ETH) attached to it.
UNSUBSCRIBE
On Tue, Sep 7, 2021 at 2:34 PM btcookies @.***> wrote:
Background Badger relies on many keepers to maintain vaults, rebase digg, collect fees, distribute rewards, and other miscellaneous tasks. These keepers are hosted across Kubernetes clusters, most of which are cron jobs that execute on set schedules and then terminate. This architecture requires private keys to be dynamically accessed at execution in order to sign and submit transactions.
Currently we are storing the keys in AWS secrets manager and restricting access to k8s service account IAM roles on a pod by pod basis. At the time of execution, the container makes a get_secret_value request via boto3 to retrieve the secret, decrypts it with kms, and passes the value into web3 to sign and submit transactions. This solution is less than ideal because the private key is able to be accessed by the program, where if code reviews are not diligent could result in the raw key value being logged or transmitted outside of the execution environment.
The proposed solution to this is to use KMS to generate and store private keys and pass transaction objects to KMS where KMS can handle signing without ever exposing the key. Here https://luhenning.medium.com/the-dark-side-of-the-elliptic-curve-signing-ethereum-transactions-with-aws-kms-in-javascript-83610d9a6f81 is a medium article explaining how KMS can be used to sign Ethereum transactions while maintaining the highest levels of security.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Badger-Finance/gitcoin/issues/30, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUC2YO7ZDZ25ZVF3UPOBKADUAZZPFANCNFSM5DTERP6Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
Work has been started.
These users each claimed they can complete the work by 1 week, 5 days from now. Please review their action plans below:
1) meetmangukiya has started work.
Python package that allows to sign and send ETH transactions using keys stored in AWS KMS. 2) sejpalkalpesh has started work.
A python package that will sign ETH transactions using AWS KMS without fetching a private key. 3) viswanathkgp12 has started work.
Shall implement ethereum KMS signer
Learn more on the Gitcoin Issue Details page.
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
Work for 350.0 BADGER (5509.00 USD @ $15.74/BADGER) has been submitted by:
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
Work for 350.0 BADGER (5509.00 USD @ $15.02/BADGER) has been submitted by:
@tritium-vlk please take a look at the submitted work:
Issue Status: 1. Open 2. Started 3. Submitted 4. Done
The funding of 350.0 BADGER (2726.50 USD @ $7.84/BADGER) attached to this issue has been approved & issued to @meetmangukiya.
Background Badger relies on many keepers to maintain vaults, rebase digg, collect fees, distribute rewards, and other miscellaneous tasks. These keepers are hosted across Kubernetes clusters, most of which are cron jobs that execute on set schedules and then terminate. This architecture requires private keys to be dynamically accessed at execution in order to sign and submit transactions.
Currently we are storing the keys in AWS secrets manager and restricting access to k8s service account IAM roles on a pod by pod basis. At the time of execution, the container makes a get_secret_value request via boto3 to retrieve the secret, decrypts it with kms, and passes the value into web3 to sign and submit transactions. This solution is less than ideal because the private key is able to be accessed by the program, where if code reviews are not diligent could result in the raw key value being logged or transmitted outside of the execution environment.
The proposed solution to this is to use KMS to generate and store private keys and pass transaction objects to KMS where KMS can handle signing without ever exposing the key. Here is a medium article explaining how KMS can be used to sign Ethereum transactions while maintaining the highest levels of security.
Desired Outcome This bounty is for creating a python solution for signing raw web3py transactions with keys generated by and hosted in KMS. The ideal solution will create a Python module that can be imported to keeper codebases and used alongside web3py to sign transactions. I should be able to submit a transaction object and a kms key arn or id and receive back a signed transaction that can be submitted to the chain. The module should have a full test suite and there should be documentation explaining how it can be tested and used.
We will pay 100 BADGER for the best quality submission with a good readme, working tests, and way to import via pypi. We will pay another 250 BADGER if/when we re successfully able to use it to sign and execute transactions via KMS.
Note that there is an AWS component here. It would be amazing/make it much faster/more likely for us to use your code if you could provide terraform modules to build out keys that worked with it and/or very good documentation on how to setup the AWS side. As you get close to completion, make sure to come to talk to us on our builder discord about integration.
Here's an example of how we're initially thinking it could be used