We are creating the backend of our mobile/web app in Amplify and we have two environments there
1- Amplify Prod
2- Amplify Dev
Currently all of our developers who have access to amplify can pull both dev and prod environment in their local systems by running the amplify pull command. What we are trying to figure out is that is there any way we can restrict them to pull the prod environment? Like when they try to pull the prod environment they need to provide a password for successful pull or just totally restrict them to pull the prod? TIA
Related
When deploying to AWS from gitlab-ci.yml file, you usually use aws-cli commands as scripts. At my current workplace, before I can use the aws-cli normally, I have to login via aws-azure-cli, authenticate via 2FA, then my workstation is given a secret key than expires after 8 hours.
Gitlab has CI/CD variables where I would usually put the AWS_ACCESS_KEY and AWS_SECRET_KEY, but I can't create IAM role to get these. So I can't use aws-cli commands in the script, which means I can't deploy.
Is there anyway to authenticate Gitlab other than this? I can reach out to our cloud services team, but that will take a week.
You can configure OpenID to retrieve temporary credentials from AWS without needing to store secrets.
In my view its actually a best practice too, to use OopenID roles instead of storing actual credentials.
Add the identity provider fir gitlab in aws
Configure the role and trust
Retrieve a temporary credential
follow this https://docs.gitlab.com/ee/ci/cloud_services/aws/ or a more detailed version https://oblcc.com/blog/configure-openid-connect-for-gitlab-and-aws/
I want to remove auth from only 1 single Amplify environment (production) using amplify remove auth.
Does this command affect all environments?
Would it delete every user pool?
amplify remove auth will delete the authentication service locally from the currently checked out environment.
To find out your current environment, run amplify status. If this is the wrong environment, run amplify env list and then amplify env checkout ENV_NAME to switch to the right one.
Running amplify remove auth will then not touch any other auth related stacks (e.g. user pools etc.) for any other environments. It will only impact the current env.
Subsequently, run amplify push to update your cloud configuration once happy.
Me and my partner are working on a web-project using AWS Amplify, where we have two different Amplify environments in which we are working. Is there a way for me to add the resources present in my partners environment to my environment? More specifically I would like to add/access the existing API gateway and Lambda functions my partner created in his environment to mine (have them show up as resources when using 'amplify status' in my environment). Is this possible?
This file aws-exports.js is the same meaning as .env
So everyone can have their own setting
Create a copy aws-exports.js and name it aws-exports.mysetting.js
When others run your project
cp aws-exports.mysetting.js aws-exports.js
I'm in the process of setting up multiple AWS accounts. The plan is to create separate accounts for each environment - DEV, QA , UAT & PROD.
Our web application is hosted using elastic beanstalk. The CI/CD pipeline will tag and deploy a version to beanstalk application in DEV account for each commit - This is working great.
We are tying to figure out how to deploy a chosen tagged version to different AWS account (QA), we will have a beanstalk application created with same name in QA as well.
I'm looking for a better way to manage the releases, please share your thoughts.
You should be able to use Named Profiles to target different accounts. The syntax might look something like eb deploy --profile qa myapp-env-qa.
I have deployed the django application on aws . I want that application should be deployed by team as well. What is procedure to do this? I have searched a lot and almost spent couple of hours . Anyone has any answer or tutorial?
Can we share these keys ?
aws_access_key_id
aws_secret_access_key
No, the AWS access keys should be kept secret and not even stored under version control.
For deployment (i.e. the credentials needed to actually release the code - used by EB), you should use an aws profile. Add a ~/.aws/credentials file with
[myprofile]
aws_access_key_id=...
aws_secret_access_key=...
and then, on all eb commands use --profile. e.g.
eb create --profile myprofile
If your application requires other AWS services (e.g. RDS, S3, SQS), then you can use the same local profile for development (although I would recommend not requiring any other AWS for testing) by using then environment variable export AWS_PROFILE=myprofile. And then rely on AWS roles and policies for the production environment.
If you feel you need the secret keys as django settings, then consider using https://django-environ.readthedocs.org where you can keep all those secrets on a .env file that gets loaded by django. But again, this file should not be under version control.
You should also create IAM users for every person in your team, so each person has its own credentials, and you can more easily monitor or if needed, revoke credentials.