Say I have an API call. It originates in a lambda that is in account 1234. It updates AWS resources in account 9876. Which account is hit for the SDK API limit? How is that determined?
I'm trying to see how scalable a management approach would be. I want to have a management account work against resources elsewhere. However, if the management account maxes out on API limits then I need to figure something else out. In thinking about AWS's existing multi-account systems, particularly Control Tower, it will stand up CloudFormation templates in other accounts. I'm not sure if that's a clue or just one of their products utilizing another one that naturally solves a kind of problem.
My use case doesn't let me simply utilize CloudFormation StackSets. The main reason for that is I need to manage 3rd party accounts and asking for delegated admin permissions is too permissive, and they only get 5 anyway.
Whenever you use API calls to perform actions on resources, the limits in the account that the resources live in are used. In almost all cases (one exception: S3 in requester pays mode) that's also the account that will have to pay for any resource usage, so it makes sense to have the limits that protect the account there.
Related
I'm working on a Slack app which will have to store access token per each customer using the app (ex. 1000 teams using it = 1000 tokens). Token enables the app to access Slack API for customers workspace and will be used frequently every day.
App will be running on AWS, using Lambda's and DynamoDB.
What would be the best practice to store those access tokens securly?
I cannot find any strict recomendation for this scenario. Was thinking initially to put those in DynamoDB in a dedicated table but thinking now if I should use other AWS services for that use case. I've checked Secrets Manager but looks like a rather expensive option and not sure if it applies to my scenario.
Appreciate any suggestions.
I would probably use a dedicated DynamoDB table for this purpose. At a minimum, I would configure it to use a KMS CMK to encrypt the data at-rest, and also restrict access to the table through fairly granular IAM permissions in your AWS account. If you also wanted to encrypt each value separately you could look into client-side encryption.
Your findings on the Secrets Manager costs are a good point. You could also look at Systems Manager Parameter Store as an alternative that is generally cheaper than Secrets Manager. Secrets Manager does have the added security of being able to set an IAM resource policy on the secret itself.
Ultimately it's up to you to determine how secure your solution needs to be, and how much you are willing to pay for that. You could even spin up an AWS HSM to encrypt the values, but that would increase the cost by quite a bit.
I basically want them to have access to create/modify anything that they create, but not really able to modify/delete existing resources.
Or in some other way put them in their own bubble.
I actually got AWS certified associate in architecture, so should have some idea of whatever you say. I forgot most of what I learned for the test.
For now I made them a PowerUser.
Thanks!
Currently, there is no elegant solution for this in a shared AWS account. If you need this level of separation, creating a sub-account is the way to achieve this.
but not really able to modify/delete existing resources.
You can use resource and/or identity tags and then allow or deny actions based on tags. E. g. you can deny any action for tags env=production. See https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html
You can create simple or more complex Tag Policies to enforce consistent resource tagging.
And there is a way to enforce the owner identity in a tag, so you can allocate costs. (just search the inet for it if you want)
Or in some other way put them in their own bubble.
To keep it simple the development is usually done on a separate (organizational) account and the developers shoup deliver a deployment script/procedure to deploy the resources to other stages (cloudformation, terraform,..) .
. i started by granting PowerUser. then SystemAdministrator
This is something... the developers should not need. If so, you could implement an SCP (Service control policies) to limit even the admin users (deny disabling the cloudtrail, access to sensitive kms, modify roles with certain tags,.. .)
I have an AWS account. There are multiple users being managed by IaM service.
Each user has access key and is at liberty to perform various actions such as files upload.
Is there any means to monitor cloud costs and usage by user?
I utilize cost explorer AWS service and intend filtering and grouping costs/usages by user. Unfortunately haven't come up with any way to nail it in the most graceful way.
One common way to do this is to use Cost Allocation Tags.
You can define these tags and enforce them, e.g. using AWS Config and/or tag policies.
AWS does not track costs by user.
When an IAM User makes a request to AWS to create resources (eg an EC2 instance or an RDS database), the user's permissions are checked to confirm that they are permitted to make that API call. If they are permitted, then the API call is allowed and the resources are created.
Resources created in an AWS Account are owned by the AWS Account, not an individual user. Thus, there is no relationship between resources and the credentials used to create the resource.
The closest link between users and resources would be the audit trail of API calls kept by AWS CloudTrail. CloudTrail stores information about the API call and the user that made the call, but it does not directly link to the resources that were created. This would take some effort to back-trace resources to users.
Typically, cost management is done by tagging resources. Such tags would identify cost centers or project codes that can be used to charge-back the cost of systems. Enforcing tagging is difficult. Only some services allow tagging to be enforced when services are launched. For others, it would be a matter of identifying resources that do not meet tagging requirements. See: Using AWS Config Rules to Manage Resource Tag Compliance | Sumo Logic
You can monitor every IAM user action through cloud trails logs. So you could imagine a solution based on those logs to calculate the cost of all actions from one IAM user
I allways recomend to have an account per user type or subscription type in your system (free or premium for exmaple). Depending on the user who use your services, you will login that use with this account. Then, using the AWS Cost Categories, you can to see the cost by users type, and then, knowing your number of users for each tipe or subscription you could know your price per user.
My company is new to AWS and I've been piloting a development effort to build a lambda function. I've finished my coding and I need to hand it off to another team. How can I allow another team member to access/run/execute/develop/etc... the lambda function from their account?
If you just want them to invoke the Lambda cross account, which was your original question, then you can delegate access to an IAM user (or all users) in the other AWS account so that they can assume a role in your account and invoke the Lambda function in your account.
Technically, you could just add IAM users to your account and give them credentials, but that is not a best practice. Cross-account roles are preferred.
But is this really what you want? It would not allow them, for example, to update the Lambda function. You need to think about what their responsibilities will be. If they are going to maintain the Lambda function then it's more likely that they should deploy the Lambda function into their account and you give their Lambda function cross-account access to whichever resources it needs in your AWS account.
If you want to share development then use a shared code repo (like GitHub or CodeCommit) and create a process, automated or otherwise, for packaging and uploading the Lambda function to your account. Again, they may need to be able to assume a cross-account IAM role in order to update and/or invoke your Lambda function.
At a higher level, if what you’re building here is actually a serverless application with an API, then consider using the serverless framework or AWS SAM, with API Gateway, for development, packaging, and deployment.
On your question about account structure, this is taking us far from the original question, so I'd recommend further reading, for example here and here. There are plenty of opinions on account strategy, some of which may be a good match depending on your needs.
Can AWS IAM be used to control access for custom applications? I heavily rely on IAM for controlling access to AWS resources. I have a custom Python app that I would like to extend to work with IAM, but I can't find any references to this being done by anyone.
I've considered the same thing, and I think it's theoretically possible. The main issue is that there's no call available in IAM that determines if a particular call is allowed (SimulateCustomPolicy may work, but that doesn't seem to be its purpose so I'm not sure it would have the throughput to handle high volumes).
As a result, you'd have to write your own IAM policy evaluator for those custom calls. I don't think that's inherently a bad thing, since it's also something you'd have to build for any other policy-based system. And the IAM policy format seems reasonable enough to be used.
I guess the short answer is, yes, it's possible, with some work. And if you do it, please open source the code so the rest of us can use it.
The only way you can manage users, create roles and groups is if you have admin access. Power users can do everything but that.
You can create a group with all the privileges you want to grant and create a user with policies attached from the group created. Create a user strictly with only programmatic access, so the app can connect with access key ID and secure key from AWS CLI.
Normally, IAM can be used to create and manage AWS users and groups, and permissions to allow and deny their access to AWS resources.
If your Python app is somehow consuming or interfacing to any AWS resource as S3, then probably you might want to look into this.
connect-on-premise-python-application-with-aws
The Python application can be upload to an S3 bucket. The application is running on a server inside the on-premise data center of a company. The focus of this tutorial is on the connection made to AWS.
Consider placing API Gateway in front of your Python app's routes.
Then you could control access using IAM.