I am working on a project with a micro-frontend structure, which is a parent Astro app hosting child React apps. Technologies used are ReactJS, with dependencies like Vite and Webpack CLI, etc.
I am using Amazon Cognito, and putting the UserPoolId & ClientId in a .env file, in the parent Astro app.
The issue is once I have deployed to AWS S3 & CloudFront Distribution. The .env file is not committed to Gitlab, so the deployed CloudFront website doesn’t know where to find the UserPoolId & ClientId.
I have been researching and can’t seem to find a good method. I have considered setting Gitlab CI/CD pipeline variables for the UserPoolId & ClientId, but I’m not sure if that is good practice. Have also considered using dotenv, but I don’t think that works for security in production environment, only in dev.
What should I do so the deployed CloudFront website could access the UserPoolId & ClientId in a secure way? What are the steps you have taken? Would love to hear your input!
2
Answers
Its a best practice to not store secrets in files. This article may be useful, I have not tried.
https://aws.amazon.com/blogs/networking-and-content-delivery/authorizationedge-how-to-use-lambdaedge-and-json-web-tokens-to-enhance-web-application-security/
It describes how you can put Cognito in front of CloudFront, and once the user signs-in, get the JWT Token generated by Cognito and have it validated at the nearest edge location by a Lambda function, specifically a Lambda@Edge deployment.
Once validated, the request is forwarded to the origin and access to the private content is possible.
You can store the sensitive variables using AWS Secrets Manager. The secrets can be injected as variable during pipeline executions.
Personally I’m using Jenkins for my CI/CD and we have fine-grained permissions so I just create a Jenkins secret text for simplification.
Or you can also mount the
.envfile from a secured volume, given that you are executing your app in a containerized environment.