Amplify-cli: Security best practices for Amplify app in a public repo

[kimfucious]

This is a question about the security aspects of a public software repo connected to Amplify via the console as part of a CI build/deploy process.

Setup

1. Init app, using amplify init
2. provision resources (e.g. api, storage, etc.) via amplify-cli
3. connect app (e.g. git repo) using the AWS Amplify console
4. git push, publishing the app

In brief, in order to get a build to work for something like the above, one needs to edit the .gitignore file to allow for the team-provider-info.json file to be checked in, rather than omitted (default).

Taking a look at this file, there is some information that _could_ be potentially exploited.

{
    "beta": {
        "awscloudformation": {
            "AuthRoleName": "MY_APPNAME_ENV-20190625175625-authRole",
            "UnauthRoleArn": "arn:aws:iam::MY_AWS_ACCOUNT_NUMBER:role/MY_APPNAME_ENV-20190625175XXX-unauthRole",
            "AuthRoleArn": "arn:aws:iam::MY_AWS_ACCOUNT_NUMBER:role/MY_APPNAME_ENV-20190625175XXX-authRole",
            "Region": "MY_REGION",
            "DeploymentBucketName": "MY_APPNAME_ENV-20190625175XXX-deployment",
            "UnauthRoleName": "MY_APPNAME_ENV-20190625175XXX-unauthRole",
            "StackName": "MY_APPNAME_ENV-20190625175XXX",
            "StackId": "arn:aws:cloudformation:MY_REGION:MY_AWS_ACCOUNT_NUMBER:stack/MYAPPNAME_ENV-20190625875XXX/e2065420-9737-11e9-9074-0299cad2cdb0"
        },
        "categories": {
            "auth": {
                "MYAPPNAME268422e5": {}
            }
        }
    }
}

The stuff IN_CAPS above is where what I see as potentially sensitive information in the wrong hands.

While I know that this particular app is locked down using Cognito authorization (I don't allow users to sign themselves up) and the IAM roles are only being used for this app and are pretty much locked down, I'm curious as to best practices for publishing this type of information in a public repo.

This only came up recently, as a potential colleague of mine asked me to share a repo, and it made me scratch my head.

I do realize that I'm being a bit paranoid, but can you ever be too paranoid with regards to security these days?

Any advice on this would be appreciated.

[kaustavghosh06]

@kimfucious The purpose of this file is basically sharing it within your team-members on the same project and want to update/use the same AWS Infrastructure tied to an environment. If you're open-sourcing your project you can totally get rid of this file (or make it a part of .gitignore).

The contents of these files are basically resource identifiers and without having access to your "secretKey" and "accessKey" tied to your AWS account, no one would be able to access these resources even if you publicly check this into yor GitHub repo.

[kimfucious]

Thanks, @kaustavghosh06

I did a search across my project's directory hierarchy for my AWS account number and came up with only results on that file.

It looks like omitting this file from the repo (and deleting all history in the repo) would clean things up toot sweet.

Though, I'm still paranoid...

[kimfucious]

I did some stuff, recently and came across some new changes in the Amplify Console / CLI tete-a-tete.

In short, I deleted my amplify app (in order to clean the history of certain files in the repo) and re-attached a new repo.

In the process the changes in the console have changed.

Now I'm being faced with:

Prior to this change I had allowed aws-exports.js into my repo (probably unwisely).

At this point, things are completely convoluted.

Before, I provisioned all backend resources via the CLI and published the app via console.

Now I'm lost in the trees.

Please send docs.

[kimfucious]

On top of this, the Domain Management process has changed, things are now broken.

[kimfucious]

Presently stuck in a loop of SSL creation, SSL configuration, SSL verification, domain activation.

I do believe the DNS is configured correctly... not sure what to do now.

[swaminator]

@kimfucious can you please share your AppARN (Found under app settings > general). You can email it to us at [email protected]

Also couple of questions:

1. When you connected your repo in the Console did you pick an existing backend?
2. Where are you seeing an error when connecting a custom domain?

[kimfucious]

Hi @swaminator thanks for reaching out regarding this.

Here's how I got into this:

1. I disconnected my app from the Amplify Console, because I changed the backing repo so as to remove the git history on a file that contained sensitive information.
2. I used connect app to attach to the new repo. Here's where I faced the new(? I'd never seen this message before) "Existing Amplify backend detected."
3. To answer your question 1 above: I selected "Only deploy the front end." This resulted in a successful build and the app being available at the https://branch.xxx.amplifyapp.com/ url.
4. I added a custom domain, clearing out the existing records at my 3rd party DNS provider, and adding in the authorization CNAME record.

The above got me into a loop, where the status details of the domain configuration were cycling between SSL configuration and SSL verification. And when I say "cycling", I would wait a while, refresh the page, and it would be one or the other.

To fix this, I wound up doing the following:

1. Remove all existing DNS records for the domain
2. Delete the domain from the AWS console
3. Re-add the domain from the AWS console
4. Add the verification record at my DNS provider
5. Wait for Available status in AWS console
6. Add in the CNAME records pointing to cloudfront.net
7. Wait for cloud front propagation

So, I'm all good. This is a "toy" app, so longer than expected outage of the URL was no big deal.

My real question, and I can open another ticket for this if you want me to, is to clarify the new(?) "Existing Amplify backend detected" part of the connection process.

1. Is this actually new, as I have not seen this before when connecting the app with an existing backend?
2. When I chose "No" a big, red warning is shown saying this isn't a good idea.
3. What is considered best practice? As I like provisioning the backend via the CLI?
4. I currently do have aws-exports.js file in my repo, but I would like to exclude it from from the repo, so that I can make the repo public.
5. What would have happened if I chose "Yes?"

[kimfucious]

I just build a fresh app using Amplify CLI to try to figure out the "Existing Amplify backend detected" stuff.

This time around I chose, "Create a New Environment" and I created a new IAM role.

The build went fine, and I did not check in the aws-exports.js file, which I think is good "security-wise"

When accessing the app, it seems like the security role I created is lacking the necessary access to the AWS resources.

I'm assuming there are extra steps necessary, to grant the IAM role access, which happens "automagically" when using the CLI?

I've been searching for some docs that cover this, but I'm not finding anything that covers this step.

Thanks.

[swaminator]

@kimfucious your app should be working out of the box as we would have deployed a new backend as part of the deployment.

Can you try and follow this tutorial: https://docs.aws.amazon.com/amplify/latest/userguide/deploy-backend.html
Also this doc might help conceptually on different workflows: https://docs.aws.amazon.com/amplify/latest/userguide/multi-environments.html

[kimfucious]

Hey, @swaminator thanks for the info and the links. Both are helpful 😄

I tore down the app, but I'll retry again and see what happens, letting you know either way.

One thing I remember is that I created a new environment, not seeing the environment that I created via the CLI, which is different from the tutorial. I'll need to do it again to be sure.

[kimfucious]

Okay, I just created a brand new app with the following steps:

1. amplify init
2. amplify add api
3. amplify push
4. connect to repo in Amplify console

It sees the backend, but it does not see the environments as it shows in step 7 here.

Have I completely lost the plot, or missed a step?

Thanks for your help.

[cslogan-red]

Hi @kimfucious, the guide assumes you've committed and pushed the resulting change to your team-provider-info.json file after creating your local CLI environment(s), you'd need this file present in your repo to integrate backend environments you've created with the CLI into the Console.

That said, there is no requirement for this if you'd rather not commit this file, the resources created with the CLI will be recreated in a new backend environment by the Console automatically if you choose the "Create new environment" option. (side note: there is nothing in the file that can be exploited without also having access to your secret and access key pair, which you should never publish)

If you'd like to then integrate the backend environment that the Console created automatically for you into your local CLI, you can do so after the app successfully builds by going to the completed build and expanding the "Backend" section of the build, follow the instructions in the dialog at the top to get the environment imported into your local CLI. This can all be done without publishing your team-provider-info.json file.

[kimfucious]

Hi @cslogan-red

Thanks for the follow up.

On a completely different app, which I created on the CLI with a default env named prod, I provisioned all my backend via the CLI, did an Amplify push, and then pushed my code into a repo and connected it via the Amplify console.

An, voila, the prod environment was there! Everything worked as expected. I'm not sure why, but I'll revisit the old app to see how i/things went wrong.

And, for the record, in addition to the team-provider-info.json file, I'm trying to keep the aws-exports.js file out of the repo. And now, I've successfully done both.

[kimfucious]

Another note on this long closed thread, is that once you start working with Cognito federatedSignIn, your third party secrets are put right into team-provider-info.json.

So, unless you're working in a private repo, best exclude this file.

FYI: I've salted the below values with dummy chars.

"categories": {
    "auth": {
        "amplifyuserpooltest0e7XXXb4": {
            "hostedUIProviderCreds": "[{\"ProviderName\":\"Google\",\"client_id\":\"3983847568769-muertqn01293847563ck1h2k7jsaq0an.apps.googleusercontent.com\",\"client_secret\":\"TjOF8-gv56473829102sF2lX\"}]"
        }
    }
}