AWS Amplify, Secured DevOps - Part 1, Why It Matters
Tags: aws, amplify, fullstack, cicd
Published: 2021-12-06 17:57:56

Well, fresh off an awesome AWS re:Invent, I wanted to put out a short series of posts about a common issue I run into talking with people about CI/CD. These posts center around the `aws-exports.js` that the CLI will generate when initializing or pulling from the Admin/Studio UI. If you're unfamiliar with this, I'd recommend starting at the [Getting Started section of the AWS Amplify Documentation](https://docs.amplify.aws/start/?sc_icampaign=start&sc_ichannel=docs-home).

What is inside the `aws-exports.js` file that makes it such a big deal, and why do we exclude it in the first place?

First, you have to understand why committing credentials into a source code repository is generally seen as a bad idea. For a good read on this, take a look at [Why storing secrets and passwords in Git is a bad idea](https://withblue.ink/2021/05/07/storing-secrets-and-passwords-in-git-is-bad.html#:~:text=Most%20developers%20working%20on%20a,%2Dsecure%20ways%2C%20etc). TL;DR: It's not a good idea, don't do it.

So with that established, let's look at the aws-exports.js file:

```javascript
// WARNING: DO NOT EDIT. This file is automatically generated by AWS Amplify. It will be overwritten.

const awsmobile = {
  aws_project_region: 'us-east-1',
  aws_cognito_identity_pool_id:
    'us-east-1:<SNIP>',
  aws_cognito_region: 'us-east-1',
  aws_user_pools_id: 'us-east-1_<SNIP>',
  aws_user_pools_web_client_id: '<SNIP>',
  oauth: {
    domain: '<SNIP>',
    scope: [
      'phone',
      'email',
      'openid',
      'profile',
      'aws.cognito.signin.user.admin'
    ],
    redirectSignIn:
      'https://<SNIP>,<SNIP>',
    redirectSignOut:
      'https://<SNIP>,<SNIP>',
    responseType: 'code'
  },
  federationTarget: 'COGNITO_USER_POOLS',
  aws_cloud_logic_custom: [
    {
      name: 'AdminQueries',
      endpoint: 'https://<SNIP>.execute-api.us-east-1.amazonaws.com/dev',
      region: 'us-east-1'
    }
  ],
  aws_appsync_graphqlEndpoint:
    'https://<SNIP>.appsync-api.us-east-1.amazonaws.com/graphql',
  aws_appsync_region: 'us-east-1',
  aws_appsync_authenticationType: 'AMAZON_COGNITO_USER_POOLS',
  aws_appsync_apiKey: '<SNIP>'
};

export default awsmobile;
```

Just look at all the places I removed information and put in `<SNIP>`. If you wouldn't post it in a Dev.To blog post, here's a good rule of thumb, you probably shouldn't commit it.

While SPA and some SSG apps might end up embedding some of these values, generally, these are keys and values that the end-user should not get ahold of, or they could start running attacks on your backend surfaces.

Imagine someone getting the `aws_appsync_apiKey` along with the `aws_appsync_graphqlEndpoint` and just starting to DDoS or brute force their way past your auth. Or just overall knowing what the architecture for your application backend is. The less information the attacker has, the slower and more challenging it is to get in and do bad things.

Now, let's talk about what generates `aws-exports.js`. Like I mentioned at the beginning when you launch `amplify init` or run `amplify pull` with the variables given from the Admin/Studio UI. When you first run those commands, it will ask you where your source folder is (default is `/src`), and it will generate this file in that folder. Every time you run `amplify pull` from then on, it will regenerate the `aws-exports.js` file with any changes on the backend. It will also regenerate if you use `amplify add <feature>` with those features' security details.

Amplify will, by default, exclude `aws-exports.js` in the `.gitignore` file. Here is an example of a `.gitignore` file I had locally:
```
#amplify
amplify/\#current-cloud-backend
amplify/.config/local-*
amplify/mock-data
amplify/backend/amplify-meta.json
amplify/backend/awscloudformation
build/
dist/
node_modules/
aws-exports.js
awsconfiguration.json
amplifyconfiguration.json
amplify-gradle-config.json
amplifyxc.config
```

If you didn't read the linked article earlier, you might be inclined to remove these lines and commit these files anyway. I hope you don't.

Lastly, this `aws-exports.js` file is what you're going to use to configure your `Amplify Libraries` SDK in your project. Eventually, I'll add an "aws-modifications.js` tutorial for a simple trick I use for modifying that file in runtime.

Hopefully, that gives you a little more idea of what is going on under the hood and why you don't want to break it. Next, I will show you a few real-world scenarios that I've used for dealing with these and other security values. Keep an eye out for Part 2.