I have my build artifacts in an S3 bucket in my dev account. I have an EC2 instance (target of deployment) and CodeDeploy setup in the prod account. Both instance profile role and CodeDeployRole have access to the bucket in dev account. From instance I can manually copy the files.
However deployment fails during download bundle phase with access denied.
Please help.
Bucket policy in dev account:
"Principal": {
"AWS": [
"arn:aws:iam:: 222222222222:role/CodeDeployRole",
"arn:aws:iam:: 222222222222:role/instanceprofilerole"
]
},
"Action": [
"s3:PutObject",
"s3:ListBucket",
"s3:GetObject",
"s3:Get*",
"s3:List*"
],
"Resource": [
"arn:aws:s3:::mybucketname",
"arn:aws:s3:::mybucketname/*"```
Related
My project uses a library from AWS CodeArtifact. I can fetch the library and build the project in my local and in the github build. When the AWS CodePipeline runs in our Dev environment, CodeArtifact returns a 401 when trying to access the library.
I updated the IAM role running the Pipeline so that it has these actions:
{
"Effect": "Allow",
"Action": [
"codeartifact:GetAuthorizationToken",
"codeartifact:GetRepositoryEndpoint",
"codeartifact:ReadFromRepository"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "sts:GetServiceBearerToken",
"Resource": "*",
"Condition": {
"StringEquals": {
"sts:AWSServiceName": "codeartifact.amazonaws.com"
}
}
}
I updated the Repository Policy to include this IAM role. The Repository Policy has these actions:
"codeartifact:DescribePackageVersion",
"codeartifact:DescribeRepository",
"codeartifact:GetPackageVersionReadme",
"codeartifact:GetPackageVersionAssets",
"codeartifact:GetRepositoryEndpoint",
"codeartifact:ListPackageVersionAssets",
"codeartifact:ListPackageVersionDependencies",
"codeartifact:ListPackageVersions",
"codeartifact:ListPackages",
"codeartifact:PublishPackageVersion",
"codeartifact:PutPackageMetadata",
"codeartifact:ReadFromRepository",
"codeartifact:GetAuthorizationToken"
My build.gradle is using the repository as described here and works in my local this way - https://medium.com/#chauyan/use-aws-codeartifact-in-your-project-7bf5d3e0d3dc
I'm guessing it has to do with the way the library was published, maybe it doesn't have the right permissions, but I don't see that the permissions are changeable here. Why am I getting a 401 from CodeArtifact when trying to build the project in CodePipeline?
You have to publish to maven central
I have launched an EC2 instance which is needed to connect to s3 bucket.
i created IAM role and linked it to EC2 instance. and from EC2 awscli i can list the files, however i deployed a container in that EC2 and when trying to list the file, I am getting the error -
An error occurred (AccessDenied) when calling the ListObjectsV2 operation: Access Denied
IAM-Role
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:ListBucket",
"s3:PutObjectAcl"
],
"Resource": [
"arn:aws:s3:::my-bucket/*",
]
}
]
}
Can somebody please suggest. why i can access the s3 from an ec2 instance but not from the container running on the same EC2 instance.
The ListBucket call is applied at the bucket level, so you need to add the bucket as a resource in your IAM policy (as written, you were just allowing access to the bucket's files):
"Resource": [
"arn:aws:s3:::my-bucket",
"arn:aws:s3:::my-bucket/*"
]
See this for more information about the resource description needed for each permission.
The fact that you were able to get the bucket listing from a shell running on the EC2 instance indicates to me that you have another user configured. Look for files in $HOME/.aws and environment variables that start with AWS.
Trying to create and run an AWS CodePipeline that pulls from Github, builds and deploys to an EC2 instance. The pipeline is as follows:
Source (Github) -> Build (AWS CodeBuild) -> Deploy (AWS CodeDeploy)
The source and build steps both succeed. However, deploy fails consistently giving the following error:
Insufficient permissions
Unable to access the artifact with Amazon S3 object key '[redacted]-2nd-test-pip/BuildArtif/IbiHzen' located in the Amazon S3 artifact bucket 'codepipeline-us-east-1-[redacted]'. The provided role does not have sufficient permissions.
Below is the IAM policy for the CodeBuild service role policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Resource": [
"arn:aws:logs:us-east-1:362490217134:log-group:/aws/codebuild/[Redacted]-Build-Project",
"arn:aws:logs:us-east-1:362490217134:log-group:/aws/codebuild/[Redacted]-Build-Project:*"
],
"Action": [
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:PutLogEvents"
]
},
{
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::codepipeline-us-east-1-*"
],
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:GetObjectVersion"
]
},
{
"Effect": "Allow",
"Resource": [
"arn:aws:s3:::codepipeline-us-east-1-[Redacted]/*"
],
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:GetObjectVersion"
]
}
]
}
The CodePipeline service role created by the pipeline wizard has assigned S3 full access:
"Action": [
"elasticbeanstalk:*",
"ec2:*",
"elasticloadbalancing:*",
"autoscaling:*",
"cloudwatch:*",
"s3:*",
"sns:*",
"cloudformation:*",
"rds:*",
"sqs:*",
"ecs:*"
],
"Resource": "*",
"Effect": "Allow"
},
I have confirmed numerous times that the artifact referenced in the pipeline deploy step matches the artifact created by the build step.
If I go and look at path referenced, there is not a directory or zip file (not sure which SHOULD be there, but neither is) with that name. Additionally, a zip file is generated during the build, but it is never named what the deploy step expects.
I've also gone into the build project and attempted builds using other artifact configurations, but they seem to be ignored when running the build through CodePipeline.
Disclaimer: I've seen similar questions posted here and elsewhere on the interwebs, but each of them deal with ECS or another situation that differs from mine. Thank you for your help
The issue was unrelated to roles/policies. As mentioned, the expected zip file did not exist in the S3 bucket. This was due to an invalid artifact files path specified in the buildspec. Once corrected, the zip file is created and the deploy no longer fails on this error. Seems odd to me that CodePipeline would allow the build to report as completed successfully without validating that the files created as the artifact and passed to the deploy step were, in fact, created.
I tried to upload image using aws-sdk, multer-s3.
In my local environment, uploading image was succeed, but in production environment(aws lambda), it fail with error status 403 forbidden.
But my aws credential key and secret-key is same as local environment. also i checked aws key in production environment successfully.
I think difference between two other environment is nothing.What am I missing?
I have even tried setting aws key in my router code like below, but it also failed.
AWS.config.accessKeyId = 'blabla';
AWS.config.secretAccessKey = 'blalbla';
AWS.config.region = 'ap-northeast-2';
and here is my policy
{
"Id": "Policy1536755128154",
"Version": "2012-10-17",
"Statement": [
{
"Sid": "Stmt1536755126539",
"Action": [
"s3:DeleteObject",
"s3:GetObject",
"s3:PutObject"
],
"Effect": "Allow",
"Resource": "arn:aws:s3:::elebooks-image/*",
"Principal": "*"
}
]
}
Update your attached s3 bucket policy to a user according to below policy:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation",
"s3:ListAllMyBuckets"
],
"Resource": "arn:aws:s3:::*"
},
{
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3:::YOUR-BUCKET",
"arn:aws:s3:::YOUR-BUCKET/*"
]
}
]
}
it's working on my server.
I haven't worked with AWS Lambda but I am familiar with S3. When you're using the AWS SDK in your local environment, you're probably using the root user with default full access, so it will just work.
With Lambda however, according to the following extract from the documentation, you need to make sure that the IAM role you specified when you created the Lambda function has the appropriate permissions to do an s3:putObject to that bucket.
Permissions for your Lambda function – Regardless of what invokes a Lambda function, AWS Lambda executes the function by assuming the IAM role (execution role) that you specify at the time you create the Lambda function. Using the permissions policy associated with this role, you grant your Lambda function the permissions that it needs. For example, if your Lambda function needs to read an object, you grant permissions for the relevant Amazon S3 actions in the permissions policy. For more information, see Manage Permissions: Using an IAM Role (Execution Role).
See Writing IAM policies: How to grant access to an S3 bucket
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.