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.
Related
I want to implement a security measure that enables any authenticated user to delete any AWS resource only on approval from any other member.
The main objective is to make sure that, if the creds are compromised, the user should not be able to delete any resource without approval.
Looking forward to get some expert advise and discussion on this.
I understand, the least access privilege and MFA, but still it is fulfilling our requirements.
Since this is not directly supported by AWS, you will have to set up a custom solution for this.
This is one possible solution:
Create a role with delete permissions.
Create a Lambda to use that role to delete a resource.
Implement the Lambda to only processes the delete request if the input includes at least two approvals. (This part depends on your org authentication mechanism. Could be LDAP, short term access tokens, etc)
This fulfills the two requirements you mentioned:
a security measure that enables any authenticated user to delete any AWS resource only on approval from any other member.
The Lambda will only process the request if there is at least 2 approvals.
if the creds are compromised, the user should not be able to delete any resource without approval.
In this design there are no credentials. The role you created can only be assumed by the Lambda. You can further improve the security by only allowing certain Users, Roles or Groups to be able to execute the Lambda.
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.
I have a multi-account strategy in AWS. All is deployed using the CDK. Each service has it's own account and I want to achieve this (recommended by this aws blog post):
If I deploy the API account first, it needs the other account's lambda ARNs for integration, which are not yet created.
If I deploy a service account first, it needs the API methods ARNs for giving them permission to invoke the lambdas.
I think this is kind of a "deadlock" situation and I can't figure it out.
Putting it in other words, how can I integrate, using the CDK, the API account's methods with lambdas from another account?
Thanks!
There's no "one size fits all" approach to problems like these.
Common approach I have previously seen:
Define the component with the least amount of dependencies on other components, let's say in this case it's the microservice
Replace the dependency parameters with placeholders, for example, instead of allowing API account to invoke the lambda, allow microservice's account to invoke it first
Now you have lambda ARNs of the microservice, which you can use in other components
Repeat until all components are deployed (but not necessarily functional)
Now you can replace placeholder values in the original microservice deployment
Looking for suggestions on an AWS use case.
I have a lot of accounts in my AWS.
I am looking to create the same policy in all of my accounts. Now I want to automate it.
1) Can I create any lambda function or cloud formation template or any way to automate the creation of the same policy in all of my accounts even if any new account is created and it needs to add to all existing accounts if it's not there?
2)If possible then how I can get access to lamda function to create policies.
Thanks
If you have multiple AWS accounts, you may want to consider using AWS Organizations and Service Control Policies (SCP). The policies are applied at a root level and affect all accounts under that root.
By using organizations, you can get events when account creation is completed and apply any additional changes to the account that you would like by using a Lambda function that receives a CloudWatch event. The event would contain information about the newly created account.
The two options that provided seem to require a lot of manual administrative overhead, but would be happy to answer your concerns. Creating Lambda function which creates policies is done using the SDK. There is an IAM method called "CreatePolicy" which provides this functionality.
If I'm understanding your needs here (and assuming they're still the same after almost 3 years), you might consider using CloudFormation StackSets instead. They allow you to define common resources, including policies, as a CloudFormation template and have that template deployed to every one of the accounts in your organization.
You'll need to enable trusted access for CloudFormation StackSets in your organization AWS account, which will allow it to deploy the stacks to the rest of your organization's accounts.
To create the stack you'll need to:
Define a CloudFormation template using either CloudFormation directly, or capturing the synthesized stack from an AWS CDK application.
Upload the produced template to a location in S3 that's accessible by your top-level organization account.
Create the StackSet in the CloudFormation console (or the CLI, CDK, etc). You can either deploy the stack to all accounts or filter by specific accounts or organizational units (OUs).
Once created, the stacks will be automatically deployed to the desired accounts, and kept up to date when the stack is updated. This will require you to define significantly less infrastructure.
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.