I am trying to make a connection between AWS IoT and my React JS APP.
I followed this tutorial (https://medium.com/serverlessguru/serverless-real-time-reactjs-app-aws-iot-mqtt-17d023954045), and it is not clear to me how to attach the Cognito Identity ID to the AWS IoT Policy.
During all my investigation, I found that this process must be done through command line.
In the article above, theses process is done by the following command line:
• Note that the “identity_pool_id” has to be considered in this command.
In the aws documentation (https://aws-amplify.github.io/docs/js/pubsub), it says to write the “identity_id” in the command line:
When I use the “identity_pool_id” in the command line, and I try to publish a message from AWS IoT, I got the following error:
When I use the “identity_id” in the command line, I can perform the communication between AWS IoT and the Frontend successfully:
The problem is that the “identity_id” is a different code for each user. Considering that I am going to have a lot of user in my application I don’t know how to perform this task.
• Am I doing the right process to consider the “identity_id” instead of “identity_pool_id”?
• If yes, how could I automatically attach the Cognito ID to the AWS IoT Policy every time I have a new user signedIn in my application?
• Are there any problem to have thousands of Cognito certificates attached in a AWS IoT Policy?
Following answer is in chronological order corresponding to 3 questions.
You can attach only identity_id (user) to IoT policy. Also, I can see you have used "attach-principal-policy" API which is deprecated now, so instead of that please use AttachPolicy API
I'm unsure here, still I'd recommend to evaluate and verify it on Cognito's post confirmation trigger
Absolutely right, you can attach a IoT policy to myriad of certificates; technically it is known as Simplified Permission Management
For #3, Relevant Snippet from AWS (Ref - https://aws.amazon.com/iot-core/faqs/ where find Q. What is Simplified Permission Management?)
"You can share a single generic policy for multiple devices. A generic policy can be shared among the same category of devices instead of creating a unique policy per device. For example, a policy that references the “serial-number” as a variable, can be attached to all the devices of the same model. When devices of the same serial number connect, policy variables will be automatically substituted by their serial-number."
Related
Following the AWS Greengrass Quickstart Docs
Install the AWS IoT Greengrass Core software step 5 leads to the error :
The security token included in the request is invalid
I have tried:
with both my normal creds, temporary creds (as recommended),
created new secret keys and retried normal and temporary creds,
tried in both v1 and v2 of Greengrass
I have tested the "export AWS_..." variables set to make sure they are properly set.
I just dont understand what is happening in GreengrassCore to try to debug if this is something with my user credentials or if something is breaking in the script itself. If it hadn't been for running into so many AWS tutorials and "Quickstarts" that were broken out of the box, outdated, and wrong I would just assume I'm doing something wrong but at this point I was wondering if anyone has been able to get this to work or if they could give me any additional insight of the security token...is invalid message when I have tried using credentials from the "My Security Credentials" and from aws sts get-session-token --duration-seconds 129600 repeatedly.
Thanks for any and all insights.
Greengrass uses the provided credentials to perform all cloud operations to provision the device, certificate, IoT policy, IoT role alias, and also an IAM role with permissions.
I've found that temporary credentials, even those with fully admin access, may not work in certain contexts. Can you try provisioning with an IAM user's set of credentials and temporarily with the AdministratorAccess IAM policy (you can remove after Greengrass has successfully provisioned).
If you want to be more specific, you can create an minimal IAM policy from here. Those are needed permissions in the credentials provided to Greengrass to complete provisioning.
You might want to review the Greengrass v2 workshop let's begin section. It covers the same as the AWS documentation but might explain things in a different way.
I want to implement Security in AWS Cloud using IAM like below:
1. Restricting Region(Possible)
2. Restricting Particular Service(EC2/RDS/VPC)(Possible)
3. Restricting IAM user(Disabled other IAM user resources)(Not Sure)
4. Deleting IAM user should delete AWS Resources created by this user.(Not Sure)
I came across Cloud Training site called Qwiklabs where they restrict exactly what I need.
I already tried and done first two restrictions(Region and Services).
Now I'm not sure for remaining 3rd and 4th.
Can anyone suggest me how to implement this scenario?
Ad 3. - Can You elaborate?
In Qwiklabs Your labs are created on separate AWS account - no other users are there.
Ad. 4 - You will have to force all users to use CloudFormation do provision resources or develop a process (Lambda/Step function) triggered by delete user action
4.Deleting IAM user should delete AWS Resources created by the user - You can use AWS Cloudtrail/AWS Lambda for that.
AWS Lambda:
https://docs.aws.amazon.com/AmazonCloudWatch/latest/events/RunLambdaSchedule.html
You can create a Lambda function which triggers as soon as the user logs in. The first Lambda function should create another Lambda Function with the scheduled events associated.
The second Lambda Function contains the specific user's information, instructions for deleting the resources created by the specific user and the instructions to delete the scheduled event.
With AWS CloudTrail:
By using the below sample command you can get the list of actions performed by the user.
aws cloudtrail lookup-events --lookup-attributes AttributeKey=username,AttributeValue=user#example.com
Once you have that you can delete them.
I am opening an AWS Service (say: AWS Rekognition) for my app's users.
The problem is: when one user (ex: user1) creates a resource (such as a collection), other users (ex: user2, user3) also see the resource that was created by user1.
I have tried to use Identity Pool, and acquired Token/Identity from my backend server for my users but things are not better (my users still see the resources of each other).
What should I do to let user1 receive user1's resource only?
I have been struggling with this problem for days, but can't seem to figure out.
Regards
There are two approaches to this architecture:
Option 1: Client/Server
In this architecture, client apps (eg on a mobile device or a web-based app) make calls to an API that is hosted by your back-end application. The back-end app then verifies the request and makes calls to AWS on behalf of the user.
The user's app never receives AWS credentials. This is very secure because the back-end app can authenticate all requests and apply business logic.
Option 2: Providing AWS credentials
In this architecture, the client apps receive temporary AWS credentials that enables them to directly call AWS services (which matches the architecture you describe).
The benefit is that the app can directly access AWS services such as Amazon S3. The downside is that they you need to very tightly limit the permissions they are given to ensure they only access the desired resources.
Some services make this easy by allowing Conditions on IAM Permissions that can limit the resources that can be accessed, such as by tag or other identifier.
However, based upon Actions, Resources, and Condition Keys for Amazon Rekognition - AWS Identity and Access Management, there is no such capability for Amazon Rekognition:
Rekognition has no service-specific context keys that can be used in the Condition element of policy statements.
I think you could limit the calls by providing a Resource string in the IAM Policy, which can limit their ability to make certain calls (eg DeleteFaces) so that it is only done against a specific collection.
However, please note that list calls such as ListCollections are either permitted fully or not at all. It is not possible to limit the list of collections returned. (This is the same as most AWS Services, such as listing EC2 instances.)
Thus, when using this method of providing credentials, you should be very careful about the permissions granted to the app.
My code is running on an EC2 machine. I use some AWS services inside the code, so I'd like to fail on start-up if those services are unavailable.
For example, I need to be able to write a file to an S3 bucket. This happens after my code's been running for several minutes, so it's painful to discover that the IAM role wasn't configured correctly only after a 5 minute delay.
Is there a way to figure out if I have PutObject permission on a specific S3 bucket+prefix? I don't want to write dummy data to figure it out.
You can programmatically test permissions by the SimulatePrincipalPolicy API
Simulate how a set of IAM policies attached to an IAM entity works with a list of API actions and AWS resources to determine the policies' effective permissions.
Check out the blog post below that introduces the API. From that post:
AWS Identity and Access Management (IAM) has added two new APIs that enable you to automate validation and auditing of permissions for your IAM users, groups, and roles. Using these two APIs, you can call the IAM policy simulator using the AWS CLI or any of the AWS SDKs. Use the new iam:SimulatePrincipalPolicy API to programmatically test your existing IAM policies, which allows you to verify that your policies have the intended effect and to identify which specific statement in a policy grants or denies access to a particular resource or action.
Source:
Introducing New APIs to Help Test Your Access Control Policies
Have you tried the AWS IAM Policy Simulator. You can use it interactively, but it also has some API capabilities that you may be able to use to accomplish what you want.
http://docs.aws.amazon.com/IAM/latest/APIReference/API_SimulateCustomPolicy.html
Option 1: Upload an actual file when you app starts to see if it succeeds.
Option 2: Use dry runs.
Many AWS commands allow for "dry runs". This would let you execute your command at the start without actually doing anything.
The AWS CLI for S3 appears to support dry runs using the --dryrun option:
http://docs.aws.amazon.com/cli/latest/reference/s3/cp.html
The Amazon EC2 docs for "Dry Run" says the following:
Checks whether you have the required permissions for the action, without actually making the request. If you have the required permissions, the request returns DryRunOperation; otherwise, it returns UnauthorizedOperation.
Reference: http://docs.aws.amazon.com/AWSEC2/latest/APIReference/CommonParameters.html
I would like to set up different AWS Identity and Access Management (IAM) users so that if an AWS resource is created by that IAM user, the resource is automatically assigned a specific tag.
For example: if IAM user F creates a new EC2 instance, the instance is automatically tagged as User:MrF. Is it possible to build a custom policy that does this?
My company GorillaStack have an open source lambda function that does exactly that.
The function 'listens' for CloudTrail logs to be delivered and tag the created resource with the ARN of the user that created it. It also support cross account tagging, for cases where a central account collects CloudTrail logs for other accounts.
Github: https://github.com/GorillaStack/auto-tag
Blog Post: http://blog.gorillastack.com/gorillastack-presents-auto-tag
It got a shout out at the 2015 re:Invent conference which is pretty cool :)
Hope that helps!
This is not available when using the AWS APIs directly (i.e. there's no way to command all AWS API's to tag new resources automatically on your behalf), however, depending on the specifics of your use case you could work around that limitation by correlating the creating user with the resource via post hoc tagging:
Workaround
You could activate AWS CloudTrail, which records AWS API calls for your account and delivers log files to you and provides exactly the information you are after:
The recorded information includes the identity of the API caller, the
time of the API call, the source IP address of the API caller, the
request parameters, and the response elements returned by the AWS
service.
Based on that information, a dedicated service of yours could analyze the logs and apply post hoc tags to all resources based on the logged user and created resource via the resp. API actions. Please see my answer to Which user launched EC2 instance? for some caveats/constraints to consider when going down this route.
An even better solution (faster plus I believe cheaper than parsing through CloudTrail logs) is to use CloudTrail but in combination with CloudWatch Events.
This is the basic concept described in a diagram
The implementation is detailed in this article:
https://blogs.aws.amazon.com/security/post/Tx150Z810KS4ZEC/How-to-Automatically-Tag-Amazon-EC2-Resources-in-Response-to-API-Events
The article also describes how to setup an IAM policy that only allows the creator of a resource to perform certain actions (like start / stop, describe, edit, terminate) against it.
I would chose AWS Config. Create a rule that automatically tags resources on creation. No cost, works across multiple accounts. Great for enforcing compliance. https://aws.amazon.com/about-aws/whats-new/2019/03/aws-config-now-supports-tagging-of-aws-config-resources/
Currently there is no such feature on IAM. If what you need is allow/deny based on user names, what you could do is use variables on your policy to allow or deny access based on naming conventions, e.g.:
...
"Resource":"arn:aws:dynamodb:us-east-!:123456789:table/ItemsCatalog_${aws:username}"
...