I am currently trying to create a Cloud9 Environment with an IAM User with AdministratorAccess
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}
But every time, I get one of the following error:
or
I am creating the Cloud9 Instance on the us-east-1 server. And this problem has been happening for a couple of days now. Does anyone know the root cause?
Related
I have a "root" account.
I created an "admin" account which has all the right.
I created an account "dev" and I want it to only have acces to certain services:
s3
dynamoDB
cloudWatch
API Gateway
Lambda
Cognito
So I created a policy with the aws console editor and I gave full access to theses ressources and allows everything, it gave me this:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"s3:*",
"apigateway:*",
"lambda:*",
"dynamodb:*",
"cognito-idp:*"
],
"Resource": "*"
}
]
}
Looks good to me (not specific enough but good for a beginner).
Problem: I created db, lambda, api gateway, etc... but I can't see the services with this, which autorisation should I give for the "dev" role to see the items in the AWS console ?
I found it, I only needed to switch my region in the top right corner of the console. (shame on me)
I've been trying to create a EKS fargate profile on my account, but I keep getting this message:
Misconfigured PodExecutionRole Trust Policy; Please add the eks-fargate-pods.amazonaws.com Service Principal
What's strange is that I'm doing this in the web console and from what I read the roles I'm being shown are only roles with that service principle. I've verified that the roles have that service principle too. Still anytime I try to create the profile, I get that message. Any ideas on what could actually be causing that?
The execution role policy looks like this:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "eks-fargate-pods.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
I followed following steps to add and configure AWS account in Spinnaker:
hal config provider aws account add my-aws-acc --account-id xxxxxxxxxxxx --assume-role SpinnakerManaged
hal config provider aws enable
AWS Account Setup
SpinnakerManaged Role is having following policies attached :
pass_role_policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:*"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*"
}
]
}
Power User Access
Server on which spinnaker is hosted is attached SpinnakerAuth Role which has following policies:
PowerUser Access
Pass_role_policy
assume_role_policy
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "sts:AssumeRole",
"Resource": "*"
}
]
}
command: hal deploy apply
Spinnaker gets successfully deployed while clouddriver service with port 7002 doesn't come up
Error in /var/log/spinnaker/cloudriver/clouddriver.log file : Caused by: com.amazonaws.services.securitytoken.model.AWSSecurityTokenServiceException: Not authorized to perform sts:AssumeRole (Service: AWSSecurityTokenService; Status Code: 403; Error Code: AccessDenied;
This is related to the trust relationship in the AWS IAM configuration. The deployment of AWS IAM permissions for the cases described below has been improved in the spinnaker.io documentation.
Use a Managing AWS User with AWS Key and Secret with the policy that allows to assume the ManagedTargetRole
Use a Managing Role with the policy that allows to assume the ManagedTargetRole
Please refer to this option and deploy again.
In my case the local debian installation in Spinnaker never worked for me. I was successfully able to deploy Spinnaker by using the project Minnaker for PoC.
Using .Net Core, visual studio 2017 and AWS Toolkit for Visual 2017, I created a basic web api, the api works as designed.
However when it comes to publishing/deploying it, the first time works perfectly when the Stack doesnt exist, creates everything its suppose to. When I make a change and need to re-deployed/publish, it comes back with the following error.
Error creating CloudFormation change set: Stack [TestStack] already exists and cannot be created again with the changeSet [Lambda-Tools-636366731897711782].
Just above the error message is this
Found existing stack: False
Im wondering if there is something not quite right with it detecting if the Stack exists.
Im just wondering if Im missing something, or if this is actually be design, as for me to republish it I have to log into my AWS Console and go into the cloud formation section and delete the existing Stack.
Publish Dialog
Project Structure
After a bit of digging, and general trial and error. I believe this is actually to do with permissions of the user performing the publish. (The user in AWS)
I changed an inline policy to
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "",
"Effect": "Allow",
"Action": [
"cloudformation:*"
],
"Resource": [
"*"
]
}
]
}
Where cloudformation:* used to be several lines for individual permissions.
This now successfully publishes over an existing Stack, however visual studio doesnt like it and crashes. (Although the update does go through to AWS)
AWS' Serverless Application Model is … very new still. And for lack of any documentation about what IAM permission one needs to deploy an App with their CLI, I've worked out this policy that seems to work, and only grants the least needed permissions for the task.
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"lambda:UpdateFunctionCode",
"s3:PutObject",
"cloudformation:DescribeStackEvents",
"cloudformation:UpdateStack",
"cloudformation:DescribeStackResource",
"cloudformation:CreateChangeSet",
"cloudformation:DescribeChangeSet",
"cloudformation:ExecuteChangeSet",
"cloudformation:GetTemplateSummary",
"cloudformation:ListChangeSets",
"cloudformation:DescribeStacks"
],
"Resource": [
"arn:aws:lambda:*:123456789012:function:*-SAM-*",
"arn:aws:cloudformation:*:123456789012:stack/<STACK NAME OR GLOB>/*",
"arn:aws:cloudformation:<AWS_REGION>:aws:transform/Serverless-2016-10-31",
"arn:aws:s3:::aws-sam-cli-managed-default-samclisourcebucket-*/*"
]
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:ListBucketMultipartUploads"
],
"Resource": "arn:aws:s3:::aws-sam-cli-managed-default-samclisourcebucket-*"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": "cloudformation:ValidateTemplate",
"Resource": "*"
}
]
}
Note:
Replace <STACK NAME OR GLOB> with something that best suits your needs, like:
* If you don't care which CloudFormation Stack this grants access to
*-SAM-* If you name your SAM CloudFormation apps with some consistency
Replace <AWS_REGION> with the region you're operating in.
The arn:aws:s3:::aws-sam-cli-managed-default-samclisourcebucket-* is the standard bucket naming that SAM CLI uses for creating a bucket for deploying CloudFormation Templates or Change Sets. You could alter this to explicitly be the name of the bucket SAM created for you.
I'm using the following set of IAM permissions for my AWS account. The goal is to allow our developers access to any "development" resources...launching from our AMIs, starting instances, stopping them, etc. As such, we've tagged the volume snapshots and the AMIs themselves. However, when I log in with a developer account in the group, I'm unable to see anything that was tagged and therefore can't do anything. Any help would be much appreciated...thanks!
{
"Version": "2012-10-17",
"Statement": [
{
"Action": "ec2:*",
"Effect": "Allow",
"Resource": "*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/Purpose": "Development"
},
"DateLessThan": {
"aws:CurrentTime": "2016-01-01T00:00:00Z"
}
}
}
]
}
EDIT: I should add that I'm trying to enable them to do this through the console, not the CLI or via the SDK.