I'm trying to add programmatically a "working" AWS account via API.
Actually I'm performing this operations:
Authentication
CreateUser (login)
CreateLoginProfile (password)
When I go on "AWS" console I get an error an if I look to the Accounts linked to the Organization I can't find my new account.
But if I go on https://console.aws.amazon.com/iam/home#/home the user is there.
Do I'm missing something? Is there any difference between USER and ACCOUNT?
Of course USER and ACCOUNT are different. An account contains users and other resources (S3 bucket, EC2 instance).
If you want to create new AWS account, you need to use Organizations API.
See:
create-account in the AWS CLI
CreateAccount documentation
Related
I'm using AWS amplify to create an app, where users can upload images using either private or public file access levels, as described in the documentation. Besides this, I've implemented a lambda function which upon request through API gateway modifies an image and returns a link to the modified image.
What I want is that a given user should be able to call the API and modify only his own images, but not that of other users; i.e. allow the AWS lambda function to use the execution role from the cognito user. If I allow the lambda function to access all data in the S3 bucket then it works fine - but I don't want users to be able to access other users images.
I've been at it for a while now, trying different things to no avail.
Now I've integrated the API with the user pool as described here:
https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-enable-cognito-user-pool.html
And then I've tried to follow this guide:
https://aws.amazon.com/premiumsupport/knowledge-center/cognito-user-pool-group/
Which does not work since the "cognito:roles" is not present in the event variable of the lambda_handler (presumably because there are not user pool groups?).
What would the right way be to go about this in an AWS Amplify app?
Primarily, I've followed this guide:
https://aws.amazon.com/premiumsupport/knowledge-center/cognito-user-pool-group/
Use API Gateway request mapping and check permissions in Lambda itself:
Use API Gateway request mapping to pass context.identity.cognitoIdentityId to Lambda. Just it should be a Lambda integration with mapping (not a Proxy integration). Another limitation is that API request should be POST, for GET it's also possible if you map cognitoIdentityId to query string.
Lambda has access to all files in S3
Implement access control check in Lambda itself. Lambda can read all permissions of the file in S3. And then see if owner is Cognito user.
I got 4 aws accounts, and i want to centralise all my logs into a single accounts for security purposes.
Meaning collect cloudwatch logs from account prod, dev and perf into an account called logs. Ideally they would end up in cloudwatch in the accounts logs, so i can process them easily with ELK.
I read about it here:
http://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CrossAccountSubscriptions.html
But i can't find a tutorial on how to set up simply the whole stack.
Any suggestions would be appreciated.
The only thing different about using CloudWatch Logs in another account is the credentials you'll need to use.
I would do it like this; in your logs account, create 3 IAM users:
prod
dev
perf
Give each of the users the necessary IAM permissions to write logs to CloudWatch logs. Also, create a set of AWS credentials for the 3 users which you will use to authenticate with.
Then in your application, depending on what stack your in, configure your code to use the relevant credentials (i.e. Dev, Prod) to write to CloudWatch logs. The only difference should be wherever in your code you create the CloudWatch logs client. You should pass the client the credentials for the relevant IAM user from your "Logs" account.
EDIT:
If you're using the CloudWatch Logs client, the idea is the same. You create the users and instead just give the client the relevant AWS credentials. You specify the creds for the user from your logs account in the /etc/awslogs/awslogs.conf. The credentials you use is what will send your logs to CloudWatch in the other account. The process you need to follow is basically documented in the AWS docs
Trying to put together an Azure ARM integration, where my code uses the Azure API to retrieve the full list of VMs in the entire subscription.
Went successfully through all the (many!) steps here to get an API user ready with all relevant IDs needed for authentication.
Using the same set of instructions, we were also able to grant this user the Reader role, for listing VMs in specific groups (we did this through the Azure UI). However, we have been unsuccessful in implementing the instructions here for setting up Reader role for this user to the entire subscription (through the CLI).
Running this:
azure role assignment create --objectId app-oid --roleName Reader --scope /subscriptions/subscription-id
Or this:
azure role assignment create --objectId app-oid --roleName Reader --subscription subscription-id --scope /subscriptions/subscription-id
Yields this:
Principals of type Application cannot validly be used in role assignments.
So currently we have no way of programmatically browsing the full set of VMs without adding a specific authorization for each Resource Group.
Does anybody know of a way that actually works to assign this permission at the subscription level?
Found the answer in the comment area of the link in the question body:
In the new portal, edit the subscription and add the role, just like you would do with a resource group. Still curious as to why the CLI doesn't support this.
The steps to use the Azure CLI to create and authorize a service principal are documents here: https://azure.microsoft.com/en-us/documentation/articles/resource-group-authenticate-service-principal-cli/
Instead of using --objectId app-oid try using -ServicePrincipalName <appId>
https://github.com/Azure/azure-powershell/issues/4776
Had the same error for role assignment with terraform
Principals of type Application cannot validly be used in role assignments.
But as described here, using the Object Id that is displayed on the overview page of the app registration in the Azure portal resulting the above error.
The solution is to get the Object Id from azure cli:
az ad sp show --id [Application (client) Id] -o json | grep objectId
# and then using this objectId assign your role
az role assignment create --role contributor —-assignee-object-id [object id] —-resource-group [MyResourceGroup]
Is it possible to set this permission through the Cloud Console UI for cloud storage? Or is it only settable through the API (for example, following the guidance in this post)
In the documentation for Google's cloud storage, one of the defined permission scopes is "domain". This allows you to specify that the read or write permission is granted to any authenticated user that is part of your Google Apps domain.
When accessing a storage container UI in the cloud console, you can set user or group permissions, but entering a naked domain with either "User" or "Group" selected results in an "Invalid Value" message when the changes are saved.
This setting is now exposed via the Cloud Console UI. You should notice 3 sections in the dropdown: user, group, and domain.
The setting is also available via the API and via the command-line utility, gsutil. To grant read access to the domain my-domain.org from gsutil, you'd do something like this:
gsutil acl ch -g my-domain.org:R gs://bucket
For example, I have a website with User A and B.
Both of them can login to my website using my own login system.
How do I make certain files from S3 accessible only to User A once he login to my website?
Note: I saw "Permission" in AWS Management Console with "Authenticated Users" option but it seems that it's meant for other S3 users only, is it something I can use to achieve my goal?
You need to use Amazon IAM - you can define what part of any S3 bucket A can see, as well as B and each will not have access to do 'anything'. In general you should never use the account ID and secret for anything, always make an IAM user have just whats needed to run your stuff. The admin user likely does not need EC2 or SQS, or SimpleDB, etc.
Federated access is great for allowing arbitrary users to sign into your website and only be granted access for say 12 hours. They get special AWSIDs for that access that will work only on the section of S3 you let them look at.