I need to recreate a new User Pool with exactly the same settings as another one and I am wondering what is the best way to do it, or if it is a standard way that I am not aware of. (maybe a faster way than using the AWS console)
My guess is, using AWS CLI :
Get user pool details: describe-user-pool
Then create a new one with the same details : create-user-pool
Any thoughts?
You should first import the resource to CloudFormation, then copy the template and deploy it as a new stack. This will give you better control over the desired configuration of the resources. Ensure you set the retention policy to retain. Losing a user pool is no fun.
It seems there is still no support for importing Cognito user pools into CloudFormation. My recommendation remains that you should be maintaining your infrastructure as code, particularly if you wish to replicate it across environments. How you accomplish it is a little more convoluted but you should just iterate on your CFN template until the configuration matches. Or if you are up for it, terraform has tooling to help you import resources
So! To answer my own question after some time gaining related experience.
The best way to go is like #AndrewGillis said:
Hold your Infrastructure As Code.
My preference I use Terraform.
Related
I'm trying to solve a problem with AWS IAM policies.
I need to allow certain users to only delete/modify resources that are tagged with their particular username (This I've solved) while also being able to create any new aws resource.
The part I haven't solved is need to be able to create resources without ability modifying any existing resources (unless they have the right tag).
Is there an existing AWS policy example that allows a user to create any resource (without granting delete/modify)? Is there a way to allow this without having to list every single aws offering and continuously update it for new offerings?
AdministratorAccess will give all rights to create all services.
See https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator
I managed to solve this problem with a rather ugly solution, but as far as I can tell it's the only solution.
I found a list of all aws actions: https://github.com/rvedotrc/aws-iam-reference
I then parsed out potentially troubling functions like anything with Delete or Terminate in the action name. I used vim/grep for this.
After that I broke that up into multiple aws_iam_group_policy statements. Each statement was attached to a corresponding group. The target users are then added to each of those groups.
Unfortunately, this is pretty ugly and required 5 different groups and policies, but it's the solution I arrived at.
Is there a quick way to find out which regions have any resources in my account? I'm specifically using the AWS .NET SDK but the answer likely applies to other AWS SDKs and the CLI since they all seem to be just wrappers to the REST API. I can obviously run all the List* methods across all regions but I'm thinking there must be a more optimal way to decide whether to query the entire region or not. Maybe something in billing, but it also needs to be relatively up-to-date, maybe within the last 5 minutes or so. Any ideas?
There is no single way to list all resources in an AWS account or in multiple regions.
Some people say that Resource Groups are a good way to list resources, but I don't think they include "everything" in an account.
AWS Config does an excellent job of keeping track of resources and their history, but it is also limited in the types of resources it tracks.
My favourite way to list resources is to use nccgroup/aws-inventory: Discover resources created in an AWS account. It's a simple HTML/JavaScript file that makes all the 'List' calls for you and shows them in a nicely formatted list.
I'm using Hashicorp vault for creating users with the AWS Secrets-Engine.
I have an issue using the AWS credentials I get, probably because it takes time for all the AWS servers to be updated with the newly created user, as it stated here
I'm using Hashicorp Vault for creating AWS users in runtime, and use the credentials I get immediately. In practice, there could be a delay of up to a few seconds until I can actually use them. Besides performing some retry mechanism, I wonder if there is a real solution to this issue or at least a more elegant solution
As AWS IAM promises eventual consistency, we cannot do anything better than delay and hope for the best. The bad part is that we don't know for how long should we sleep till the new keys reach all endpoints.
This is the problem with the behavior of IAM, not really a Vault issue. There's kinda workaround like this:
make a new temporary user, generate keys for it, hand the keys over to the Vault requester
2.use a non-temporary user, make a new key pair for it, etc
Didn't test it, but as an idea to try I guess it's ok.
HashiCorp released a change in how they handle the dynamically created IAM users and the Vault provider now accounts for this delay. https://github.com/terraform-providers/terraform-provider-vault/blob/master/CHANGELOG.md#260-november-08-2019 Since this update I rarely run into issues but they occur once in a while.
When building lambdas for example using cloudformation. It is easy to start allowing a little too much by allowing * on resources and eventually ending up hardening/tightening your security. Is it somehow possible to view which permissions actually are in use? And by that way, figuring out what the minimal set of permissions that is needed.
This is a popular request. One option is to leverage Netflix's Aardvark and RepoKid. Another is to ensure that CloudTrail Logs are enabled and then find a way to query them (for example using Athena).
Have you tried:
AWS Policy Simulator
I have not seen anything exactly as you described, but I believe this tool would actually in the end give you what you need and also make you more and more familiar with all of the policies in IAM.
I'm working on client-side SDK for my product (based on AWS). Workflow is as follows:
User of SDK somehow uploads data to some S3 bucket
User somehow saves command on some queue in SQS
One of the worker on EC2 polls the queue, executes operation and sends notification via SNS. This point seems to be clear.
As you might have noticed, there are quite some unclear points about access management here. Is there any common practice to provide access to AWS services (S3 and SQS in this case) for 3rd-party users of such SDK?
Options which I see at the moment:
We create IAM-user for users of the SDK which have access to some S3 resources and write permission for SQS.
We create additional server/layer between AWS and SDK which is writing messages to SQS instead of users as well as provides one-time short-living link for SDK to write data directly to S3.
First one seems to be OK, however I'm hesitant that I'm missing some obvious issues here. Second one seems to have a problem with scalability - if this layer will be down, whole system won't work.
P.S.
I tried my best to explain the situation, however I'm afraid that question might still lack some context. If you want more clarification - don't hesitate to write a comment.
I recommend you look closely at Temporary Security Credentials in order to limit customer access to only what they need, when they need it.
Keep in mind with any solution to this kind of problem, it depends on your scale, your customers, and what you are ok exposing to your customers.
With your first option, letting the customer directly use IAM or temporary credentials exposes knowledge to them that AWS is under the hood (since they can easily see requests leaving their system). It has the potential for them to make their own AWS requests using those credentials, beyond what your code can validate & control.
Your second option is better since it addresses this - by making your server the only point-of-contact for AWS, allowing you to perform input validation / etc before sending customer provided data to AWS. It also lets you replace the implementation easily without affecting customers. On availablily/scalability concerns, that's what EC2 (and similar services) are for.
Again, all of this depends on your scale and your customers. For a toy application where you have a very small set of customers, simpler may be better for the purposes of getting something working sooner (rather than building & paying for a whole lot of infrastructure for something that may not be used).