I just started exploring aws system manager feature.
I am using python 3.6 and boto3 to test ssm.
I have created the Ubuntu server EC2(t2 micro) and assigned the IAM role with policy "AmazonEC2RoleforSSM", which as per my knowledge should allow running ssm send command on that EC2. But, instead I get below error:
botocore.errorfactory.InvalidInstanceId: An error occurred (InvalidInstanceId) when calling the SendCommand operation:
I even tried to check the output of:
ssm.describe_instance_information()['InstanceInformationList'])
It doesn't have the instance Id I created, which pretty much tells the story why I am getting that error. But, to my knowledge if I assign the IAM role with above mentioned policy it should show up in the list.
Strangely when I try to do above setup with Amazon Linux AMI server and run ssm everything looks good.
any idea why ssm not working in ubuntu server? I am missing something?
But, to my knowledge if I assign the IAM role with above mentioned
policy it should show up in the list.
No, there's much more to it than that. You need to install the AWS SSM agent on each server you want to manage. The reason it is working for you with Amazon Linux is that the latest version of Amazon Linux has the SSM agent pre-installed.
Related
I'm trying to use the aws inspector service (the new one, not the classic one) and I created an Amazon Linux 2 instance, and I attached the AmazonSSMManagedInstanceCore role and so the instance appeared in the fleet manager but the aws inspector doesn't find any package vulnerabilities in the instance. I can only make it work when I choose the "Amazon Linux 2 AMI with Amazon Inspector Agent" image. Is there something missing to make it work in the default instance?
I already tried using the default Amazon Linux 2 instance, but it only worked with the instance with the agent already installed
The Amazon Inspector Agent needs to be installed in order to run the Amazon Inspector. If you want to use the default AMI or any other AMI. You can use userdata to install the Amazon Inspector Agent or run SSM document to do the installation.
https://docs.aws.amazon.com/inspector/v1/userguide/inspector_installing-uninstalling-agents.html#install-linux
We're using the Ansible ec2 module to start instances in an external teams environment, and the module succeeds from the Ansible end but looking at the console it does not register any changes. We are able to successfully stop instances, but not start instances. I've tried to mimic the behavior using the AWSCLI from our AWS bastion host, and that produces the same error where the VM goes into a 'Pending' state, but does not start. We've configured the AWSCLI to use an IAM Profile for authentication vs AWS keys due to constraints from our client, we use this same configuration for our AWS Ansible modules. The profile seems like it has all the necessary permissions based on the AWS documentation. Currently it has the 'AmazonEC2FullAccess' policy as the only policy associated with our role. I would think that would be enough, if we're able to stop instances successfully via those policies, why wouldn't we be able to start? Unless there may be another permission needed? What are we doing incorrectly?
Are there any security considerations in terms of installing the AWS CLI by making as part of baking an image AMI?
I can see the following ways in which AWS CLI can be installed:
1. Via baking image (i.e. making AWS CLI as part of Base AMI itself)
2. Via cloud init
3. Install it as pre-requisite just before your service bootstraps.
I see a strong NO (from internal community) on the above for the reason that the AWS instance (spinnaker managed) can do more than just accessing cloud native resources and is very powerful. So In this case, if we tighten the spinnaker IAM role in which it deploys instances, should it be fine?
It really depends on what are you going to do with the AWS CLI in each EC2 baked instance. IS it for debugging purposes? is it part of the functionality of your system?
if is debugging only you can enable AWS CLI but leave an AWS IAM role with minimum permissions attached. You could have a role with special permissions that you can attach to your desired instances, access the instance and perform your debugging actions.
Other than that it really is not recommended that you use AWs CLI or package installation managers inside instances.
There is a document in system manager which is used to kill the process running inside the EC2 Instance and it is working correctly through AWS Console.Everytime i used to put the value the service to kill and it is killing it. But I want to revoke this System Manager "Run Command" from the Lambda.
Please help me.. I am new on Lambda.
Assuming your Lambda function's IAM role has SSM related necessary permissions, you can use the AWS SDK for the SSM service to run the SSM document to solve your purpose. For example, if you're using Python runtime for your Lambda function, you initiate a Boto3 SSM client, and use send_command() to run the SSM document you wish to run. Hope this helps!
so I have been trying to setup code deploy for my application, but it keeps on failing. Initially, I didn't have an appspec.yml file in repository, so I got the error message that the appspec.yml file doesn't exist.
I have now included an appspec.yml file, but it still doesn't work and it doesn't give any error message. There are no events mentioned, like it used to before adding the appspec file.
I have less than a beginner's knowledge when it comes to creating a appspec.yml file, but I took hint from a youtube tutorial, and here is the file.
version: 0.0
os: linux
files:
- source: /
destination: /var/www/cms
If it helps, the ec2 instance is running an ubuntu server, /var/www/cms is that directory out of which the nginx is supposed to serve files.
The most likely problem you're facing is that the agent either isn't installed or the instance doesn't have sufficient permissions. When there are no events started on the instance for the deployment, it means that CodeDeploy couldn't talk to the host for some reasons.
Here's the steps I would take:
Confirm that you installed the CodeDeploy agent
Confirm that you've created the IAM service role
Confirm that you have the IAM Instance Profile and that it's associated with the instance
Check that you can reach the CodeDeploy commands endpoint in your region from the box. i.e. ping codedeploy.us-east-1.amazonaws.com Otherwise, your networking setup might be too restrictive.
Look at the logs on the host to see what's going on
I faced at sometime this thing and it was due to the following:
If we initially created and turned on the ec2 instance without setting the IAM service role, and after that we added the service role, it will not take effect until we restart the instance.
I had attached IAM role to EC2 instance but I did not restart my systemd service. And that was the cause of failure.
Also, without rebooting instance, you can just restart systemd service of codedeploy-agent.
In case it helps, I had the same problem and the reason was that codedeploy agent was not installed in the ec2 instance.
After installing it, everything worked like a charm.