Amplify-cli: KMS support

[cptflammin]

Is your feature request related to a problem? Please describe.
Setting api keys in env or in code is not best practice.

Describe the solution you'd like
AWS provides KMS in that context. Being able to manage keys via amplify-cli would be helpful

Describe alternatives you've considered
Implemented KMS in lambda script, command line api key encryption and mangment in console in KMS

Additional context
c.f AWS doc.. :)

[UnleashedMind]

Thanks @cptflammin
Could you describe the feature request in more details?
What api keys are we referring to? how will KMS be used in this context? It'd be great if you can describe it in a user work flow.

[cptflammin]

I mean API keys for external api access (e.g. transport apis) throughout HTTP requests
In order to avoid having the key stored in versioned files or environment, I am using this by AWS KMS:
1) Setup KMS in AWS console, get THE_KMS_KEY_ID
2) in terminal, to generate "CiphertextBlob" stored then in APIconfig.myAPI1.encryptedKey
$> aws kms encrypt --key-id {THE_KMS_KEY_ID} --plaintext {THE_API_KEY}

3) TS code in lambda:

AWS.config.region = 'eu-west-1';
let apiKey: string = '';

    try {
        const ciphertextBlob: string = APIconfig.myAPI1.encryptedKey;

        var kms = new AWS.KMS();

        const decryptedKey = await kms.decrypt({
            CiphertextBlob: Buffer.from(ciphertextBlob, 'base64'),
        }).promise();
        apiKey = decryptedKey.Plaintext!.toString();
    } catch (e) {
        console.error(e, e.stack); // an error occurred
        return {
            statusCode: 500,
            body: JSON.stringify({
                message: 'apiKey failed to be decrypted',
            }),
        };
    }
  const requestConfig: AxiosRequestConfig = {
        headers: {
            'Content-Type': 'application/json',
            'Authorization-Key': apiKey,
            'User-Agent': 'not your business. really'
        },
    };

try {
        const response = await axios.post(
            APIconfig.myAPI1.url,
            the_query,
            requestConfig,
        );

[...]

[jkeys-ecg-nmsu]

Seems like you're re-implementing Secrets Manager. It would be nice to have plug-n-play Secrets Manager integration with Cognito pools so you could let your client application query against your secrets based on your Cognito setup.

[UnleashedMind]

Still not 100% sure what your feature request is about.
Are you suggesting to add a new category in the the amplify-cli to help you with using the KMS service? then aws cli is already doing that. The amplify cli focuses on setting up and update backend resource for your frontend project, instead of doing general management on your aws resources.

[cptflammin]

Hi,
back from US, yes, passwords are sensitive data and it would prefer to have the possibility to handle keys encrpytion with amplify cli as it is tightly related to amplify backend

[hatertron3000]

Chiming in to echo jkeys-ecg-nmsu. The ability to create and read secrets from Secrets Manager would be quite nice.

If an application requires a secret to be used by other resources, like Lambda functions, it would be nice to create that secret with Amplify CLI, then be able to grant access to it by other applications from the CLI. Right now, I'm modifying the PolicyDocuments in CloudFormation templates to grant access to the secret, and storing values like the secret name, and ARN as CloudFormation environment variables in the template's parameters.json file.

Please point it out if this is just my own ignorance and there's a better way to store/access a secret from Lambda functions created by Amplify CLI, while preventing exposure in the console or in repositories as an environment variable.

[kldeb]

@cptflammin how is this approach working for you? I also need to access third party apis in my amplify project.

[cptflammin]

I am using KMS from the lambda function with the above code. It avoids exposing secret keys in unencrypted environment variables or .env files. Unless I am mistaking, beware of the fact that your KMS key is attached to a specific region and not globally like s3