We have a few elastic beanstalk applications and want to set up users that can see the events, status and logs for those applications in the AWS console. They should however not be able to even see the configuration. Is this possible? If I try to include ALL the actions apart from DescribeConfigurationSettings then that user cannot view the environment at all. So it appears that I have to use Describe* to allow the user to even access the environment.
Do I have to make them use the eb cli to fetch the logs or is there away to construct a policy so that they can view an environment but basically can not access the Configuration part of the environment
Related
How do I update the IAM security credentials in the environmental variables in an Elastic Beanstalk application?
In my application I'm getting the following error sending a message to the AWS SQS queue. 403 (Forbidden)
bundle.js:27819 Error: The security token included in the request is invalid.
I changed my IAM credentials so I'm assuming I need to update the environmental variables in my Elastic Beanstalk application, and I'm assuming this is the reason for the above error.
I tried to update the security credentials in the environmental variables in my Elastic Beanstalk application by running aws configure. If I'm understanding correctly it has updated the credentials file in my .aws folder. But I don't think it updated the security credentials in the environmental variables in my AWS Elastic Beanstalk application. How to do this?
Thanks!
I tried to update the security credentials in the environmental variables in my Elastic Beanstalk application by running aws configure.
That is incorrect assumption, aws configure updates only .aws contents, which has nothing to do with ElasticBeanstalk environment variables.
If you need to update EB environment variables, then you need to use this command
eb setenv key=value
BUT, and this is a huge but, never store your credentials in a place such as remote instance. That is not how you are supposed to give permissions to your applications. Of course you can do that using environment variables but that is a huge security risk. You should create appropriate role and attach it to your EB environment instead. That way you don't need to manage your credentials and give your application all the permission it needs.
I as an admin have created several Elastic Beanstalk applications in AWS.
Now I want to give some of my team members access to login into AWS and view EBS logs - I mean read-only access. I don't want them to be able to update or deploy or crate new Elastic Beanstalk application.
If I give them AWSElasticBeanstalkReadOnlyAccess the user is unable to see anything in Elastic Beanstalk.
Look at the section Enabling Read-Only Access to Elastic Beanstalk Logs
on this page - https://docs.aws.amazon.com/elasticbeanstalk/latest/dg/AWSHowTo.iam.managed-policies.html
The mistake I was doing is the region of two users were different. Admin user configured the cloud watch logs in region N. Virginia for support user. When support user was login the default region was Ohio and support user was unable to see logs. After selecting N. Virginia region for support the support user can see logs.
I'm logging into a role through SSO and I'm trying to create a new Elastic Beanstalk environment (newest tomcat if it matters) and I am getting the following error which is preventing me from even getting the environment started building:
(Namespace: 'aws:elasticbeanstalk:environment', OptionName: 'ServiceRole'): Invalid service role
This is happening even when I am trying to clone an existing environment. I've tried to auto generate a service role and to manually create one. Both are giving the error. This error does not happen when I am logging into a user with the same permissions.
When you clone an environment using the Elastic Beanstalk console, you have the option to choose a new platform and a service role. Service role is a new concept in beanstalk documented here. Service is not required if you are using basic health monitoring but it is required if you choose to use enhanced health monitoring.
When creating an environment you can choose to pass an IamInstanceProfile (typically named aws-elasticbeanstalk-ec2-role) and a service role (typically named aws-elasticbeanstalk-service-role). These two roles are required when using Enhanced Application Health Monitoring.
Please note that these two roles require a completely a different set of permissions and you should use different roles for each of them. You can find the list of permissions required for Service Role and Instance profile documented here.
When creating/cloning/modifying environments using AWS console you will be shown an option to choose a service role. If you have never used a Service role before, you will be presented with an option to "Create a new role". The console allows you to create the Service role required by beanstalk using a single button click. You can view the permissions before creating the role.
After the first create, the console will present you with a dropdown with the role you created previously (typically named aws-elasticbeanstalk-service-role) and you can reuse this service role.
From the documentation: "A service role is the IAM role that Elastic Beanstalk assumes when calling other services on your behalf. Elastic Beanstalk uses the service role that you specify when creating an Elastic Beanstalk environment when it calls Amazon Elastic Compute Cloud (Amazon EC2), Elastic Load Balancing, and Auto Scaling APIs to gather information about the health of its AWS resources."
When creating/using a role you need to make sure the IAM user has pass role permission for the role you created. In case you are not using the root account make sure you have the correct policies for the IAM user.
Note the iam:PassRole permission allows your IAM user to pass the role to beanstalk service.
Update
There was an issue with Single Sign On that has now been resolved. Please update here or in the AWS forum thread below if you are still seeing issues.
AWS forum thread: https://forums.aws.amazon.com/thread.jspa?threadID=171369
I got the same error yesterday and a different one today using the same stack "Unable to assign role. Please verify that you have permission to pass this role: XXXXXX."
And I solved assigning this policy "AWSElasticBeanstalkFullAccess" to my user
Here you could read more:
http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/concepts-roles.html#concepts-roles-user
There seems to be a thread on aws support forum here: https://forums.aws.amazon.com/thread.jspa?messageID=670359
I am having the same issue when trying to access a beanstalk environment via crossaccount iam policy.
I think that logging into console with an IAM account that belongs to that particular AWS account with resolve the issue. Im certain AWS folks are working on it
I have everything setup and working with rolling deploys and being able to do git aws.push but how do I add a authorized key to EB server so my CI server can deploy as well?
Since you are using Shippable, I found this guide on Continuous Delivery using Shippable and Amazon Elastic Beanstalk that shows how to set it up on their end. Specifically, step 3 is what you are looking for.
It doesn't look like you need an authorized key, instead, you just need to give an AWS ID and AWS Secret Key that will allow Shippable to make API calls on your behalf. To do this, I recommend creating an IAM role that is specifically for Shippable. That way you can revoke it if you ever need to and only give it the permissions that it needs.
When using the web UI for AWS Elastic Beanstalk Environment management, I see:
Code change deployments will complete faster if you associate an
instance profile with this environment.
(also see this forum post mentioning the same thing: http://www.infosys.tuwien.ac.at/staff/leitner/cs_study/forum/viewtopic.php?pid=186#p186)
What is an instance profile? Why does it matter? How does it work / what is it doing?
I found these articles:
http://docs.aws.amazon.com/IAM/latest/UserGuide/instance-profiles.html
http://docs.aws.amazon.com/cli/latest/reference/iam/create-instance-profile.html
but I still don't understand instance profiles.
Like Celine said in the comment above, instance profiles allow you to associate an IAM role to your instance. This IAM role must be provided with certain permissions to access your AWS resources. Your EC2 instance (launched by Elastic Beanstalk) can then perform certain extra tasks. For example if you launch a worker tier environment with Elastic Beanstalk the daemon needs to poll from SQS queue, publish metrics to cloudwatch from the EC2 instance. This means that the EC2 instance needs some credentials to poll from a queue. If you have an IAM role with appropriate policies associated with the EC2 instance you essentially permit your instance to call SQS using the credentials of that role.
You can do other interesting things like automatic log publication to your S3 bucket if you have an instance profile associated with your environment.
Having an instance profile allows you to control permissions you want to give to the instance and also frees you from storing long term credentials on all your EC2 instances.
From the documentation:
Instance profiles provide applications and services access to AWS
resources. For example, your application may require access to
DynamoDB. Every API request made to AWS services must be signed using
AWS security credentials. One way to grant applications access to AWS
resources is to distribute your credentials to each instance; however,
distributing long-term credentials to each instance is challenging to
manage and a potential security risk. Instead, you can create an IAM
role with the permissions that applications require when the
application makes calls to other AWS resources. When AWS Elastic
Beanstalk launches the Amazon EC2 instances, it uses the instance
profile associated with that role. All applications that run on the
instances can use the role credentials to sign requests. Because role
credentials are temporary and rotated automatically, you don't have to
worry about long-term security risks.
The message you are seeing on the console regarding console is recommending you to use an instance profile because that allows your EC2 instance to take a faster path to deploy your application version each time you update your environment with a new copy of your source code. The end result is the same but having an instance profile enables optimizations in deployment speed which are not possible without one.
You can read more about instance profiles with Elastic Beanstalk here.
Although you can create a custom role and associate it with a beanstalk environment by giving it appropriate permissions, you can for convenience just get a default role when you launch an environnment using the AWS console. You will have the option of choosing which role you want to associate with an environment in the create environment wizard.