AWS EC2 Instance Metadata || Difference between IMDSV1 and IMDSV2 || EC2 Security || Configure IMDS

Hello Dear All, my name is Amit. I am here to give some tips and tricks about cloud learning and some day to day problem solving methods. I'm an professional cloud engineer, working in this fields for 12+ years.
If you have any queries regarding AWS issues... feel free to reach out to me.
In this video, I have discussed EC2 Instance Metadata which is, data about your Amazon EC2 instances that you can use to configure and manage your instances. It is accessible from within the instances and can be used to retrieve information such as the instance's public IP address, IAM role, and other metadata.
EC2 Instance Metadata is available in two versions, version 1 (v1) and version 2 (v2).
EC2 Instance Metadata v1 provides access to basic instance metadata and user data, but has a few limitations. It only provides data over HTTP, and the available data is limited.
EC2 Instance Metadata v2 provides a more comprehensive and secure way of accessing EC2 instance metadata. It provides the same information as v1, but also includes data on instance identity and access to the EC2 Instance Connect API. It provides data over both HTTP and HTTPS and includes improved security features such as signature verification and token-based access.
In conclusion, EC2 Instance Metadata v2 provides a more comprehensive and secure way to access EC2 instance metadata compared to v1. It is recommended to use v2 whenever possible, especially for use cases that require higher security.
Codebase: github.com/nspacer/instance-m...
My email Id : [e-mail]
Patreon: patreon.com/BeyondtheCloud56
facebook: / beyondthecloud2022
Linkedin: / beyondthecloud2023
#aws #amazonwebservices #software #softwareengineer #developers #clouds #cloudengineer #cloudcomputing #systemdesign #database #programming #fullstack #cloudsecurity #security #fullstacksoftwareengineering #itindustry #engineering #engineer #beyondthecloud #AWSSystemsmanager #AWSdocuments #AWSautomation #s3 #S3sucurity #yamlfile #jsontemplate #python #pythonprogramming #awsec2 #awsec2security #ec2security #instancemetadata #ec2
@BeABetterDev @AWSTutorialsOnline @cluut @TinyTechnicalTutorials @BlockExplorerMedia @nickchapsas @itversity @TechwithLucy @Intellipaat @knowledgeindia @SimplilearnOfficial @TechnicalGuftgu @MachineLearningHub @edurekaIN @in28minutes @CodeWithHarry @QuickSupport @byluckysir

[@beyondthecloud]

Please provide your valuable feedback in the comment section. Please like share and subscribe for more upcoming content.

[@msowrirajan]

Valuable topic. Good work! Thank you!

[@beyondthecloud]

Much appreciated!

[@bepositive6525]

Thanks for the video… helpful

[@beyondthecloud]

Thanks a lot

[@user-uq2xc5qd1b]

Great video, thanks!

[@beyondthecloud]

Glad you liked it!

[@kishoru3475]

Such a great video !!

[@beyondthecloud]

Glad you liked it!!

[@rajatjaiwal71]

informative video 👍

[@beyondthecloud]

Glad you liked it

[@amanuelyohannes7151]

Thanks for the video. I don't understand how the V2 is more secure than V1 if we can get the access key ID, secrete access key and session token on both versions? Very long details but I missed the crucial point

[@grahamschuckman3483]

Agreed, that part was somewhat glossed over. The main reason V2 is more secure is that it prevents an attacker from OUTSIDE the EC2 instance making a request agains the instance's IMDS. That is why it blocks the X-Forwarded-For header. With IMDSV1, if, for example, someone had misconfigured an nginx server running on the EC2 instance to forward along all GET requests, an attacker could connect to the public hostname of the instance and make a GET request against IMDS and have it respond back. This is a common type of SSRF attack. Switching from GET to PUT is also more secure, as many WAFs will often block PUT requests, so this also helps to prevent an outside attacker from getting access to the instance metadata. You are correct that if an attacker already has a shell on the instance, it does not really matter if we are using IMDSV1 or IMDSV2, since neither method would provide any protection at that point.

[@beyondthecloud]

Good question! Although AWS considers the existing instance metadata service (IMDSv1) to be secure, with IMDSv2, AWS adds protection for four types of vulnerabilities that could be used to gain unwanted access to Instance Metadata. IMDSv2 offer extra protection against: Open Website Application Firewalls Open reverse proxies SSRF vulnerabilities Open layer 3 firewalls and NATs At its core, IMDSv2 enhances Instance Metadata access by protecting every request with session authentication. To achieve this, IMDSv2 requires a PUT request to initiate a session and retrieve a secret token. Next, the secret token is used as a password to make requests to IMDSv2 for metadata and credentials. Unlike traditional passwords, you don’t need to worry about getting the token, because the software gets it for itself with the PUT request. The token is never stored by IMDSv2 and can never be retrieved by subsequent calls, so a session and its token are effectively destroyed when the process using the token terminates. It becomes interesting once you know that with IMDSv2, the PUT response containing the secret token can, by default, not travel outside the instance. This is accomplished by having a default Time To Live (TTL) on the low-level IP packets containing the secret token set to “1”. Hardware and software that handle packets, including EC2 instances, subtract 1 from each packet’s TTL whenever they pass it on. If the TTL gets to 0, the packet is discarded. A packet with a TTL of “n” can therefore make n “hops” in a network before giving up, while a packet with a TTL of “1” can exist in just one. In the context of IMDSv2, we refer to hop limit of the PUT call instead of TTL. By using a default hop limit (TTL) of 1, a session token can only be used directly from the EC2 instance where that session was initiated.

[@sahasraracharla8129]

Thanks for the great video. Informative and well explained. I have a question about "http-put-response-hop-limit". Can you explain what it does when the value is changed to 2/3..64

[@beyondthecloud]

Dear Sahasra, this http-put-response-hop-limit actually restricts your response to travel. By default the hop limit is 1 and can be increased upto 64. That means if you are working in simple ec2 and calling any aws service you will fine with 1 hop limit as there is nothing between. Now think of a scenario where you are running docker inside aws ec2 and within docker you want to access other aws service. You cannot do that because docker runs on its own network inside. So you have to increase the hop limit to 2 so that you can call other aws service from inside docker. Similarly if you kubernetes nods and pods you need to configure your hop limit accordingly. The main problem with the hop limit is that you will not get correct error message if you run into this problem. You sometimes have to figure it our by your own. I hope you understood it. Good luck

[@sunilguragol6395]

In my Env all servers are using pvt network not public,Is this required to update the imdv2 and how it will be access to other users ,As in your case you are using public ipv address, Please suggest on this.

[@beyondthecloud]

its not mandatory but recommended

[@aneesqureshi4823]

Hi sir I have directly upgraded from Version 1 to version 2 with out token in future if I want to Retrive meta data which token should I use? Kindly clear it

[@beyondthecloud]

Thanks for your comment. In future if you want to retrieve metadata, you must generate the token for V2 and access the meta data service.

[@aneesqureshi4823]

@@beyondthecloud generating the Token is the same procedure as u mentioned in the video right?

[@aneesqureshi4823]

@@beyondthecloud can u share me the document?

[@user-mr6ws1dq8d]

If generating a token is the same procedure, then anyone can generate a token and will share the information. kindly explain me if am wrong?

[@beyondthecloud]

Thanks for your comment. Basically in IMDSV2 you can segregate the request by request header. You can reject the request if it is not authorised.