AWS Service-To-Service authentication via Identity document

Question

In AWS, Instance identity documents are signed documents that describe instance metadata such as private IP, image ID, etc. An identity document for an instance A an be obtained from instance A using a simple HTTP request to the Metadata service (at 169.254.169.254).

In the "Practical Cloud Security" book, the following Service-to-Service authentication method is described: An instance fetches its identity document and presents it to the target VM B. VM B validates the signature and deduces the caller's identity.

I have mixed feelings about this authentication mechanism. Firstly, if instance A authenticates to both instances B and C, the authentication token appears to leak (now both B and C have it). If the authentication is inside the same VPC, the IP address should provide the same guarantees as the identity document token. Finally, there appear to be no freshness guarantees inside the token.

What is the best intended use case for this authentication mechanism?

Answer 1

There's some useful information in this github thread.

And you're right, the authentication can only be used once, and while it has no expiry it has a start datetime -- and the authenticating service can choose to authenticate only if the start datetime is x minutes ago (value of x would depend on a few factors).

Generally, in AWS you'd use IAM to authenticate communication from an EC2 to a separate service (e.g secrets manager, SQS etc) and hence you won't really need this document. However for some other services (e.g. Hashicorp Vault) you would need some other level of identity, and this is where the document might be useful.

For example, an ASG spins up a new EC2, the information of the EC2 (including it's instance id) is sent via a separate channel to Vault for reference. Once the EC2 is fully up, the application inside the EC2 makes a call to Vault using the document. Vault verifies the document, and validates that the instance id is authorizes to retrieve a secret. It then provides that secret.

There's a couple of caveats, the document can only be used one time, otherwise multiple applications might retrieve the same secret by re-using the document. Vault doesn't need to verify the source ip address as they might be in different VPCs with Nat-ing enabled etc.