Best practices when publishing to Github: should ARNs be removed from the serverless.yml?

Serverless Framework
, , ,
1

I am about to make my Github repo public and share my project with the world. That includes my serverless.yml.

My serverless.yml file contains the ARNs of my layer, DynamoDB table and S3 bucket. For example:

service: name-of-my-app
frameworkVersion: '2'

provider:
  ...
  iamRoleStatements:
    - Effect: "Allow"
      Action:
       - dynamodb:Query
       - dynamodb:Scan
       - dynamodb:GetItem
       - dynamodb:PutItem
       - dynamodb:UpdateItem
       - dynamodb:DeleteItem
      Resource: 
        - arn:aws:dynamodb:us-east-1:12345678901:table/my_table_name
    - Effect: "Allow"
      Action:
       - s3:GetObject
       - s3:PutObject
       - s3:PutObjectAcl
      Resource: 
        - arn:aws:s3:::my-s3-bucket-name/*

Is there anything wrong with doing this? Anything containing credentials will be private, obviously, but I am not sure if ARNs should be kept private too. If so, how do you achieve this?

2

I don’t think it’s the worst thing, but better to avoid. One way you could do it is to store the arn in system centre parameter store on AWS. You can then refer to that within the serverless.yml file), it has built in support with ‘ssm:’.

A bigger security warning for you is to remember that your git history will be public too so it’s no use just taking things out before making things public if you were already using git privately. It can be best to just start fresh and copy the files across to a brand new public repo.

1 Like
3

Thanks for the reply. I will look into to using parameter store. Will it still work when I run offline? Right now I have both a dev and production bucket, a dev and production DynamoDB etc. and I switch between them depending on the stage. The ability to reference the bucket and table name whilst running in offline mode is important.

Also, are there any actual risks you can think of if I did actually publish the ARNs? I know it’s probably best to avoid but I’m wondering more generally if there’s anything an attacker can do with them. My layer ARNs for example, those layers CAN’T be referenced by anyone other than me, right?

4

Speaking for myself, I take the view that all information is useful to a hacker so I avoid putting anything that could be of use to a malicious actor into anything that could be made, both intentionally and unintentionally, public.

Yes, it’s a pain. But I view it as paying forward.