Giter VIP home page Giter VIP logo

aws / amazon-ec2-metadata-mock Goto Github PK

View Code? Open in Web Editor NEW
257.0 19.0 43.0 717 KB

A tool to simulate Amazon EC2 instance metadata

Home Page: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

License: Apache License 2.0

Go 50.43% Dockerfile 0.28% Makefile 2.84% Shell 44.96% Mustache 1.49%
aws-ec2 ec2-instance-metadata spot-interruption-mock scheduled-events-mock ec2-instance-metadata-mock hacktoberfest

amazon-ec2-metadata-mock's Introduction

Amazon EC2 Metadata Mock

Amazon EC2 Metadata Mock (AEMM) is a tool to simulate Amazon EC2 instance metadata service for local testing.


latest release go-version license docker-pulls

EC2 Metadata Mock CI and Release

Table of Contents

Summary

AWS EC2 Instance metadata is data about your instance that you can use to configure or manage the running instance. Instance metadata is divided into categories like hostname, instance id, maintenance events, spot instance action. See the complete list of metadata categories here.

The instance metadata can be accessed from within the instance. Some instance metadata is available only when an instance is affected by the event. E.g. A Spot instance's metadata item spot/instance-action is available only when AWS decides to interrupt the Spot instance. These bring forth some challenges like not being able to test one's application in the event of Spot interruption or other such events and requiring an EC2 instance for testing. This project attempts to bridge these gaps by providing mocks for most of these metadata categories. The mock responses are designed to replicate those from the actual instance metadata service for accurate, local testing.

Major Features

  • Simulate Spot Instance Interruption (ITN) & EC2 Rebalance Recommendation events for Spot instances
  • Delay mock response from the mock serve start time
  • Configure metadata in mock responses via CLI flags, config file, env variables
  • IMDSv1 and v2 support (configurable for IMDSv2 support only)
  • Save processed configuration to a local file

Supported Metadata Categories

AEMM supports most metadata categories except for:

  • ancestor-ami-ids
  • events/maintenance/history

PRs for any of the above paths are always welcome! Please see our Contributing section for details.

Windows Metadata

Paths specific to Windows instances such as elastic-gpus/associations/elastic-gpu-id will not be supported at this time. Feel free to open an issue to discuss if you would like AEMM to support these paths in the future.

Getting Started

AEMM is simple to get up and running.

Installation

Install w/ Homebrew

brew tap aws/tap
brew install ec2-metadata-mock

Install w/ Curl

MacOS/Linux

curl -Lo ec2-metadata-mock https://github.com/aws/amazon-ec2-metadata-mock/releases/download/v1.11.2/ec2-metadata-mock-`uname | tr '[:upper:]' '[:lower:]'`-amd64
chmod +x ec2-metadata-mock

ARM Linux

curl -Lo ec2-metadata-mock https://github.com/aws/amazon-ec2-metadata-mock/releases/download/v1.11.2/ec2-metadata-mock-linux-arm
curl -Lo ec2-metadata-mock https://github.com/aws/amazon-ec2-metadata-mock/releases/download/v1.11.2/ec2-metadata-mock-linux-arm64

Windows

curl -Lo ec2-metadata-mock https://github.com/aws/amazon-ec2-metadata-mock/releases/download/v1.11.2/ec2-metadata-mock-windows-amd64.exe

Install w/ Docker

docker pull public.ecr.aws/aws-ec2/amazon-ec2-metadata-mock:v1.11.2
docker run -it --rm -p 1338:1338 public.ecr.aws/aws-ec2/amazon-ec2-metadata-mock:v1.11.2

On Kubernetes

Supported versions

  • Kubernetes >= 1.14

Helm

We are hosting helm-charts for Amazon EC2 Metadata Mock in ecr-public. The chart for this project is hosted in helm/amazon-ec2-metadata-mock.

Detailed instructions on installing Amazon EC2 Metadata Mock using Helm can be found here Helm README

kubectl

kubectl apply -f https://github.com/aws/amazon-ec2-metadata-mock/releases/download/v1.11.2/all-resources.yaml

Starting AEMM

Use ec2-metadata-mock --help to view examples and explanations of supported flags and commands:

$ ec2-metadata-mock --help

ec2-metadata-mock is a tool to mock Amazon EC2 instance metadata.

Usage:
  ec2-metadata-mock <command> [arguments] [flags]
  ec2-metadata-mock [command]

Examples:
  ec2-metadata-mock --mock-delay-sec 10	mocks all metadata paths
  ec2-metadata-mock spot --action terminate	mocks spot ITN only

Available Commands:
  events      Mock EC2 maintenance events
  help        Help about any command
  spot        Mock EC2 Spot interruption notice

Flags:
  -c, --config-file string              config file for cli input parameters in json format (default: $HOME/aemm-config.json)
  -h, --help                            help for ec2-metadata-mock
  -n, --hostname string                 the HTTP hostname for the mock url (default: 0.0.0.0)
  -I, --imdsv2                          whether to enable IMDSv2 only, requiring a session token when submitting requests (default: false, meaning both IMDS v1 and v2 are enabled)
  -d, --mock-delay-sec int              spot itn delay in seconds, relative to the application start time (default: 0 seconds)
  -x, --mock-ip-count int               number of IPs in a cluster that can receive a Spot Interrupt Notice and/or Scheduled Event (default 2)
      --mock-trigger-time string        spot itn trigger time in RFC3339 format. This takes priority over mock-delay-sec (default: none)
  -p, --port string                     the HTTP port where the mock runs (default: 1338)
      --rebalance-delay-sec int         rebalance rec delay in seconds, relative to the application start time (default: 0 seconds)
      --rebalance-trigger-time string   rebalance rec trigger time in RFC3339 format. This takes priority over rebalance-delay-sec (default: none)
  -s, --save-config-to-file             whether to save processed config from all input sources in .ec2-metadata-mock/.aemm-config-used.json in $HOME or working dir, if homedir is not found (default: false)
      --version                         version for ec2-metadata-mock

Use "ec2-metadata-mock [command] --help" for more information about a command.

Starting AEMM with default configurations using ec2-metadata-mock will start the server on the default host and port:

$ ec2-metadata-mock

Initiating ec2-metadata-mock for all mocks on port 1338
Serving the following routes: /latest/meta-data/product-codes, /latest/meta-data/iam/info, /latest/meta-data/instance-type, ...(truncated for readability)

Making a Request

With the server running, send a request to one of the supported routes above using curl localhost:1338/<route>. Example request to display all supported routes:

$ curl localhost:1338/latest/meta-data

ami-id
ami-launch-index
ami-manifest-path
block-device-mapping/
elastic-inference/
events/
hostname
iam/
instance-action
instance-id
instance-life-cycle
instance-type
kernel-id
local-hostname
local-ipv4
mac
network/
placement/
product-codes
public-hostname
public-ipv4
public-keys/
ramdisk-id
reservation-id
security-groups
services/
spot/
tags/

Configuration

AEMM's wide-range of configurability ranges from overriding port numbers to enabling IMDSv2-only to updating specific metadata values and paths. These configurations can be loaded from various sources with a deterministic precedence.

Defaults

Defaults for AEMM configuration are sourced throughout code. Examples below:

Overrides

AEMM supports configuration from various sources including: cli flags, env variables, and config files. Details regarding configuration steps, behavior, and precedence are outlined here.

Usage

AEMM is primarily used as a developer tool to help test behavior related to Metadata Service. Popular use cases include: emulating spot instance interrupts after a designated delay, mocking scheduled maintenance events, IMDSv2 migrations, and requesting static metadata. This section outlines the common use cases of AEMM; advanced usage and behavior are documented here.

Spot Interruption

To view the available flags for the Spot Interruption command use spot --help:

$ ec2-metadata-mock spot --help
Mock EC2 Spot interruption notice

Usage:
  ec2-metadata-mock spot [--action ACTION] [flags]

Aliases:
  spot

Examples:
  ec2-metadata-mock spot -h 	spot help
  ec2-metadata-mock spot -d 5 --action terminate		mocks spot interruption only

Flags:
  -a, --action string                  action in the spot interruption notice (default: terminate)
                                       action can be one of the following: terminate,hibernate,stop
  -h, --help                           help for spot
  -r, --rebalance-rec-time string      rebalance rec time specifies the approximate time when the rebalance recommendation notification will be emitted in RFC3339 format
  -t, --time string                    termination time specifies the approximate time when the spot instance will receive the shutdown signal in RFC3339 format to execute instance action E.g. 2020-01-07T01:03:47Z (default: request time + 2 minutes in UTC)

Global Flags:
  -c, --config-file string              config file for cli input parameters in json format (default: $HOME/aemm-config.json)
  -n, --hostname string                 the HTTP hostname for the mock url (default: 0.0.0.0)
  -I, --imdsv2                          whether to enable IMDSv2 only, requiring a session token when submitting requests (default: false, meaning both IMDS v1 and v2 are enabled)
  -d, --mock-delay-sec int              spot itn delay in seconds, relative to the application start time (default: 0 seconds)
  -x, --mock-ip-count int               number of IPs in a cluster that can receive a Spot Interrupt Notice and/or Scheduled Event (default 2)
      --mock-trigger-time string        spot itn trigger time in RFC3339 format. This takes priority over mock-delay-sec (default: none)
  -p, --port string                     the HTTP port where the mock runs (default: 1338)
      --rebalance-delay-sec int         rebalance rec delay in seconds, relative to the application start time (default: 0 seconds)
      --rebalance-trigger-time string   rebalance rec trigger time in RFC3339 format. This takes priority over rebalance-delay-sec (default: none)
  -s, --save-config-to-file             whether to save processed config from all input sources in .ec2-metadata-mock/.aemm-config-used.json in $HOME or working dir, if homedir is not found (default: false)

1.) Starting AEMM with spot: spot routes available immediately:

$ ec2-metadata-mock spot
Initiating ec2-metadata-mock for EC2 Spot interruption notice on port 1338
Serving the following routes: ... (truncated for readability)

Send the request:

$ curl localhost:1338/latest/meta-data/spot/instance-action
{
	"action": "terminate",
	"time": "2020-04-24T17:11:44Z"
}

2.) Starting AEMM with spot after Delay: Users can apply a delay duration in seconds for when the spot metadata will become available:

$ ec2-metadata-mock spot -d 10
Initiating ec2-metadata-mock for EC2 Spot interruption notice on port 1338

Flags:
mock-delay-sec: 10

Serving the following routes: ... (truncated for readability)

Sending a request to spot paths before the delay has passed will return 404 - Not Found:

$ curl localhost:1338/latest/meta-data/spot/instance-action

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
  <title>404 - Not Found</title>
 </head>
 <body>
  <h1>404 - Not Found</h1>
 </body>
</html>


// Server log
Delaying the response by 10s as requested. The mock response will be available in 2s. Returning `notFoundResponse` for now

Once the delay is complete, querying spot paths return expected results:

$ curl localhost:1338/latest/meta-data/spot/instance-action

{
	"action": "terminate",
	"time": "2020-04-24T17:19:32Z"
}

Alternatively a trigger time can be configured using --mock-trigger-time which can be useful to synchronize spot interruption simulation over multiple instances.

EC2 Instance Rebalance Recommendation

The Rebalance Recommendation notification is also available under the spot command as it is sent when EC2 emits this signal when Spot Instances are at an elevated risk of interruption:

$ ec2-metadata-mock spot
Initiating ec2-metadata-mock for EC2 Spot interruption notice on port 1338
Serving the following routes: ... (truncated for readability)

Send the request:

$ curl localhost:1338/latest/meta-data/events/recommendations/rebalance
{
        "noticeTime": "2020-10-16T19:18:24Z"
}

Note: although Rebalance Recommendation path contains events it will not be available when starting AEMM with the events command

Events

Similar to spot, the events command, view the local flags using events --help:

$ ec2-metadata-mock events --help
Mock EC2 Scheduled Events

Usage:
  ec2-metadata-mock events [--code CODE] [--state STATE] [--not-after] [--not-before-deadline] [flags]

Aliases:
  events, se, scheduledevents

Examples:
  ec2-metadata-mock events -h 	events help
  ec2-metadata-mock events -o instance-stop --state active -d		mocks an active and upcoming scheduled event for instance stop with a deadline for the event start time

Flags:
  -o, --code string                  event code in the scheduled event (default: system-reboot)
                                     event-code can be one of the following: instance-reboot,system-reboot,system-maintenance,instance-retirement,instance-stop
  -h, --help                         help for events
  -a, --not-after string             the latest end time for the scheduled event in RFC3339 format E.g. 2020-01-07T01:03:47Z default: application start time + 7 days in UTC))
  -b, --not-before string            the earliest start time for the scheduled event in RFC3339 format E.g. 2020-01-07T01:03:47Z (default: application start time in UTC)
  -l, --not-before-deadline string   the deadline for starting the event in RFC3339 format E.g. 2020-01-07T01:03:47Z (default: application start time + 9 days in UTC)
  -t, --state string                 state of the scheduled event (default: active)
                                     state can be one of the following: active,completed,canceled

(Truncated Global Flags for readability)

1.) Starting AEMM with events: events route available immediately and spot routes will no longer be available due to the implementation of Commands detailed here:

$ ec2-metadata-mock events --code instance-reboot -a 2020-01-07T01:03:47Z  -b 2020-01-01T01:03:47Z -l 2020-01-10T01:03:47Z --state completed
Initiating ec2-metadata-mock for EC2 Events on port 1338
Serving the following routes: ... (truncated for readability)

Send the request:

$ curl localhost:1338/latest/meta-data/events/maintenance/scheduled
{
	"Code": "instance-reboot",
	"Description": "The instance is scheduled for instance-reboot",
	"State": "completed",
	"EventId": "instance-event-1234567890abcdef0",
	"NotBefore": "1 Jan 2020 01:03:47 GMT",
	"NotAfter": "7 Jan 2020 01:03:47 GMT",
	"NotBeforeDeadline": "10 Jan 2020 01:03:47 GMT"
}

Instance Metadata Service Versions

AEMM supports both versions of Instance Metadata service. By default, AEMM starts with supporting v1 and v2; however, it is possible to enable IMDSv2 only via overrides.

1.) Starting AEMM with IMDSv2 only: session tokens are required for all requests; v1 requests will return 401 - Unauthorized:

$ ec2-metadata-mock --imdsv2

Send a v1 request:

$ curl localhost:1338/latest/meta-data/mac

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
      <title>401 - Unauthorized</title>
   </head>
   <body>
      <h1>401 - Unauthorized</h1>
   </body>
</html>

Send a v2 request:

TOKEN=`curl -X PUT "localhost:1338/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600"` \
&& curl -H "X-aws-ec2-metadata-token: $TOKEN" localhost:1338/latest/meta-data/mac
0e:49:61:0f:c3:11

Requesting a token outside the TTL bounds (between 1-2600 seconds) will return 400 - Bad Request:

$ curl -X PUT "localhost:1338/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 0"
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
   <head>
      <title>400 - Bad Request</title>
   </head>
   <body>
      <h1>400 - Bad Request</h1>
   </body>
</html>

Providing an expired token is synonymous to no token at all resulting in 401 - Unauthorized.

Static Metadata

Static metadata is classified as instance-specific metadata that is always available regardless of which command is used to start the tool.

Examples of static metadata include all metadata categories from the non-dynamic category table (ami-id, instance-id, mac) except for events and spot categories (classified as commands in AEMM).

Note that 'static' naming is used within the context of this tool ONLY

1.) Requesting static metadata instance-id:

$ ec2-metadata-mock

Send the request:

$ curl localhost:1338/latest/meta-data/instance-id
i-1234567890abcdef0

Details on overriding static metadata values and behavior can be found here

Troubleshooting

Warnings and Expected Outcome

Warning Displayed Cause Effect
Warning: Config File file name Not Found in locations input configuration file not found other input sources are used (See above for details)
Warning: Failed to save the final configuration to local file - Failed to create directory for final configuration at path/to/dir: error string Failure to create the hidden directory .amazon-ec2-metadata-mock to store the final configuration file configuration used by the tool is NOT saved to a local file. The tool continues with its primary job of mocking metadata paths
Warning: Failed to save the final configuration to local file - The destination 'path/to/dir' for saving the configuration already exists, but is not a directory Failure to create the hidden directory .amazon-ec2-metadata-mock to store the final configuration file, because a resource by that name already exists configuration used by the tool is NOT saved to a local file. The tool continues with its primary job of mocking metadata paths
Warning: Failed to save the final configuration to local file path/to/local/file: error string Failure to save final configuration to a file configuration used by the tool is NOT saved to a local file. The tool continues with its primary job of mocking metadata paths
Warning: Failed to find home directory due to error: error string Failure to get home directory working directory is used instead

Integrations

aws-node-termination-handler uses AEMM in its e2e test suite to mock the metadata service and interrupt events.

In the NTH imds-v2-test, Helm is used to download the latest AEMM release, install it onto the cluster, and start it with imdsv2-only access. NTH then acquires the v2 token from AEMM, consumes the interrupt event, then cordons the worker node and evicts the test pod, thus validating NTH functionality. For more details on NTH e2e tests refer to the documentation here.

Building

For build instructions, please consult BUILD.md

Communication

If you've run into a bug or have a new feature request, please open an issue.

Check out the open source Amazon EC2 Spot Instances Integrations Roadmap to see what we're working on and give us feedback!

Contributing

Contributions are welcome! Please read our guidelines and our Code of Conduct

License

This project is licensed under the Apache-2.0 License.

amazon-ec2-metadata-mock's People

Contributors

anuraaga avatar austinsiu avatar bobbyc avatar bruecktech avatar brycahta avatar bwagner5 avatar cjerad avatar dbyron-sf avatar dependabot[bot] avatar ihamburglar avatar julian3xl avatar likithavemulapalli avatar pdk27 avatar renanqts avatar snay2 avatar techiscool avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

amazon-ec2-metadata-mock's Issues

Userdata formatting

Working on a PR for adding userdata. We were talking about the formatting of userdata as it can be multi-line. Base64 was suggested.

Userdata in getHandlerPairs()?

Does userdata need to be registered, in this function?

func getHandlerPairs(cmd *cobra.Command, config cfg.Config) []handlerPair {
// always register these paths
handlerPairs := []handlerPair{
{path: "/", handler: handlers.ListRoutesHandler},
{path: "/latest", handler: handlers.ListRoutesHandler},
{path: static.ServicePath, handler: handlers.ListRoutesHandler},
{path: dynamic.ServicePath, handler: handlers.ListRoutesHandler},
}

It seems like things work without it, what does this function do exactly? Is it actually needed?

Support dynamic data?

Hi team,

I am building a 'aws-glue' development environment in my local computer. When I build the dev environment, aws-glue needs dynamic data when I use amazon-ec2-metadata-mock to similar metadata service. Do you have plan to support dynamic data, such as '/latest/dynamic/instance-identity/document' in the future release?

NOTE: I already build my own patch in my fork.

Support trailing / and subpath listings

ec2-metadata-mock should support a trailing slash:

## CURRENT BEHAVIOR
$ curl localhost:1338/latest/meta-data/instance-type/
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
  <title>404 - Not Found</title>
 </head>
 <body>
  <h1>404 - Not Found</h1>
 </body>
</html>

## Without the trailing slash works fine
$ curl localhost:1338/latest/meta-data/instance-type
m4.xlarge

## SHOULD RETURN
$ ec2-metadata-mock -p 1338 &
$ curl localhost:1338/latest/meta-data/instance-type/
m4.xlarge

Also, when querying paths, ec2-metadata-mock should list the subpaths:

## CURRENT BEHAVIOR
$ ec2-metadata-mock -p 1338 &
$ curl localhost:1338/latest/meta-data/spot
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
 <head>
  <title>404 - Not Found</title>
 </head>
 <body>
  <h1>404 - Not Found</h1>
 </body>
</html>

## SHOULD RETURN
$ curl localhost:1338/latest/meta-data/spot
instance-action
termination-time

Deploy Helm Chart

Describe the feature
It would be great to be able to install amazon-ec2-metatdata-mock from a chart repository to ease the install process.

Is the feature request related to a problem?
It is the standard to install hosted charts and not need to either download the release and unpack it or clone the repo to install it.

Describe alternatives you've considered
It can be cumbersome to install via the current approaches, and would make it much cleaner to have the chart hosted.

Please document how to serve real credentials in the mocked data

For the purposes of testing an application relying on the IMDS metadata service, I'd like to be able to serve valid AWS credentials via the mocked IMDS.

I'd love to have documentation for how to translate ~/.aws/credentials into the relevant pieces of the mock configuration, or better yet, an option to serve up a particular profile from those credentials as the mocked data.

Cannot simulate 404 w/Rebalance Recommendation

Issue

  • Users should be able to simulate a 404 on Rebalance Rec until it becomes available
    • this functionality already exists for Spot ITN using mock-delay-sec or mock-trigger-time
  • The only way to get 404 response on Rebalance path today is by starting with events subcmd

Desired State

  • Users can start AEMM so that RebalanceRec path returns 404, then it eventually returns valid response to simulate an instance "receiving" the Rebalance notice

Emulate specifying `PUT` response hop limit

Describe the feature
When configuring IMDS, users are able to specify a PUT response hop limit for instance metadata requests. AEMM should be able to do the same.

Is the feature request related to a problem?
N/A

Describe alternatives you've considered
N/A, want to align AEMM as close to IMDS as possible

Passing null value in AEMM config parameter

Hi i would like to ask whether is there any way how to pass null value in some of property by env variable such as AEMM_METADATA_VALUES_IAM_SECURITY_CREDENTIALS_TOKEN: null or maybe like AEMM_METADATA_VALUES_IAM_SECURITY_CREDENTIALS: '{"Code":"Success"","LastUpdated":"2020-04-02T18:50:40Z","Type":"AWS-HMAC","AccessKeyId":"MY_ACCESS_KEY","SecretAccessKey":"MY_SECRET_KEY","Token":null,"Expiration":"2040-04-02T00:49:51Z"}"'.
In my case it's still overriden by default values from the code, or in case of passing the whole json content i cannot obtain the specified values, they're empty.
Thank you a lot for any hint/workaround.

Optionally support the removal of instances tags within returned metadata

Describe the feature
It would be great if the mock could simulate the optional inclusion of instances tags within the returned metadata. To ensure backwards compatibility, the proposal would be to include a flag for omitting the inclusion of instance tags, --exclude-instance-tags. In doing so, the mock would need to respond in the same way as the real IMDS service by returning a 404 upon any request to the /tags instance category.

Bizarrely if you curl IMDS using the /tags/instance path, you get a 200 and a blank response. So I guess this behaviour will need to be also mimicked.

Is the feature request related to a problem?
It is an enhancement to better align the mock with the real IMDS service. It also expands the possible testing use cases

Describe alternatives you've considered
Alternative solutions for me would be to use a hybrid approach in my testing, which is cumbersome.

Conform the real IMDS by not listing dirs

Describe the feature
A concise description of the feature and desired behavior.

Today, AEMM lists the dirs when curling paths:

curl 127.0.0.1:1338/latest/meta-data/network/interfaces/macs
0e:49:61:0f:c3:11/device-number
0e:49:61:0f:c3:11/interface-id
0e:49:61:0f:c3:11/ipv4-associations/192.0.2.54
0e:49:61:0f:c3:11/ipv6s
0e:49:61:0f:c3:11/local-hostname
0e:49:61:0f:c3:11/local-ipv4s
0e:49:61:0f:c3:11/mac
0e:49:61:0f:c3:11/network-card-index
0e:49:61:0f:c3:11/owner-id
0e:49:61:0f:c3:11/public-hostname
0e:49:61:0f:c3:11/public-ipv4s
0e:49:61:0f:c3:11/security-group-ids
0e:49:61:0f:c3:11/security-groups
0e:49:61:0f:c3:11/subnet-id
0e:49:61:0f:c3:11/subnet-ipv4-cidr-block
0e:49:61:0f:c3:11/subnet-ipv6-cidr-blocks
0e:49:61:0f:c3:11/vpc-id
0e:49:61:0f:c3:11/vpc-ipv4-cidr-block/
0e:49:61:0f:c3:11/vpc-ipv6-cidr-blocks%

The real IMDS does not list dirs:

curl 169.254.169.254/latest/meta-data/network/interfaces/macs
0e:49:61:0f:c3:11

Since AEMM is a mock of IMDS, it should closely resemble the actual service responses.

Is the feature request related to a problem?
A description of what the problem is. For example: I'm frustrated when [...]

When using IMDS in the amazon-eks-ami repo as a testing tool, we ran into this discrepancy:
https://github.com/awslabs/amazon-eks-ami/pull/931/files#diff-049390d14bc3ea2d7882ff0f108e2802ad9b043336c5fa637e93581d9a7fdfc2R399

Describe alternatives you've considered
A description of any alternative solutions or features you've considered.

We've added more text processing to work with both AEMM and the real IMDS, but that extra code is not desirable.

Provide this mock as a Java library

Describe the feature
This mock could be provided in a form of a Java library so that integration tests for Java applications could easily use it.

Is the feature request related to a problem?
The problem is that if there is no way to install this software on the test workers that makes it difficult to use

marketplaceProductCodes field is typed as a string instead of a list of strings

Describe the bug
The marketplaceProductCodes field in the instance identity document structure is typed as a string. This doesn't match the structure of the real document, in which it is a list of strings (as documented).

Steps to reproduce

  1. Create a file overrides.json with the following contents:
{
	"dynamic": {
		"values": {
			"instance-identity-document": {
				"accountId": "123456789012",
				"architecture": "x86_64",
				"availabilityZone": "us-east-1a",
				"billingProducts": null,
				"devpayProductCodes": null,
				"marketplaceProductCodes": [
					"4i20ezfza3p7xx2kt2g8weu2u"
				],
				"imageId": "ami-02f471c4f805553d3",
				"instanceId": "i-048bcb15d2686eec7",
				"instanceType": "t2.nano",
				"kernelId": null,
				"pendingTime": "2022-06-23T06:21:55Z",
				"privateIp": "172.31.85.190",
				"ramdiskId": null,
				"region": "us-east-1",
				"version": "2017-09-30"
			}
		}
	}
}
  1. Run ec2-metadata-mock -c overrides.json.

The program exits with an error message about the type of the marketplaceProductCodes field.

Expected outcome
The application starts up and serves the supplied instance identity document.

Application Logs

$ ec2-metadata-mock -c overrides.json 
Using configuration from file:  overrides.json
Error: Fatal error while attempting to load viper config: 1 error(s) decoding:

* 'dynamic.values.instance-identity-document.MarketplaceProductCodes' expected type 'string', got unconvertible type '[]interface {}', value: '[4i20ezfza3p7xx2kt2g8weu2u]'
Usage:
  ec2-metadata-mock <command> [arguments] [flags]
  ec2-metadata-mock [command]

Examples:
  ec2-metadata-mock --mock-delay-sec 10 mocks all metadata paths
  ec2-metadata-mock spot --action terminate     mocks spot ITN only

Available Commands:
  completion  generate the autocompletion script for the specified shell
  events      Mock EC2 maintenance events
  help        Help about any command
  spot        Mock EC2 Spot interruption notice

Flags:
  -c, --config-file string              config file for cli input parameters in json format (default: $HOME/aemm-config.json)
  -h, --help                            help for ec2-metadata-mock
  -n, --hostname string                 the HTTP hostname for the mock url (default: 0.0.0.0)
  -I, --imdsv2                          whether to enable IMDSv2 only, requiring a session token when submitting requests (default: false, meaning both IMDS v1 and v2 are enabled)
  -d, --mock-delay-sec int              spot itn delay in seconds, relative to the application start time (default: 0 seconds)
  -x, --mock-ip-count int               number of IPs in a cluster that can receive a Spot Interrupt Notice and/or Scheduled Event (default 2)
      --mock-trigger-time string        spot itn trigger time in RFC3339 format. This takes priority over mock-delay-sec (default: none)
  -p, --port string                     the HTTP port where the mock runs (default: 1338)
      --rebalance-delay-sec int         rebalance rec delay in seconds, relative to the application start time (default: 0 seconds)
      --rebalance-trigger-time string   rebalance rec trigger time in RFC3339 format. This takes priority over rebalance-delay-sec (default: none)
  -s, --save-config-to-file             whether to save processed config from all input sources in .ec2-metadata-mock/.aemm-config-used.json in $HOME or working dir, if homedir is not found (default: false)
  -v, --version                         version for ec2-metadata-mock

Use "ec2-metadata-mock [command] --help" for more information about a command.

panic: Fatal error while executing the root command: Fatal error while attempting to load viper config: 1 error(s) decoding:

* 'dynamic.values.instance-identity-document.MarketplaceProductCodes' expected type 'string', got unconvertible type '[]interface {}', value: '[4i20ezfza3p7xx2kt2g8weu2u]'

goroutine 1 [running]:
main.main()
        /amazon-ec2-metadata-mock/cmd/amazon-ec2-metadata-mock.go:25 +0x73

Environment

  • AEMM Version: v1.10.1
  • OS/Arch: macOS 11.6.2
  • Installation method: Homebrew

Need advise on using AEMM

@bwagner5 First of all thank you for introducing me AEMM. Please advise.

What is available with me ? I had to fix my kops cluster issues and now it's stable and it has been upgraded to the version where it supports this startergy. So you maybe reading it again I, apologize for that.

  1. Spot instances as a kubernetes nodes are provisioned. I used spot Allocation: capacity optimized startergy.
  2. Attached the IG's with the cluster auto scaler
  3. aws-node-termination handler daemon set has been installed on the newly created spot nodes. I see the logs it has connected with the IMDVS2
  4. Sample stateless web application deployed on the nodes and it's running
    What is needed?

Highly helpful if you could give me the list of commands to connect with the spot instance with this AEMM
1. On same name space I should install this AEMM or any name space is fine ? Should I install this on the non spot instance which I'm not using for this testing right ?
2. Command to connect a specific spot instance with AEMM?. So that my application will be migrated to the other spot instance which is available
3. Command to interrupt the spot request / instance?
3. How to check the spot interruption notice / any termination notice as such ?
4. End goal is that I should see the logs related to spot interruption and node draining of the spot and stateless application migration to other available nodes in the AWS node termination handler before it get's terminated if my understanding is correct.

https://github.com/aws/amazon-ec2-metadata-mock/blob/master/docs/usage.md

Can't Run Binary: command not found

OS + Kernel: 5.6.8-1-MANJARO

What I Did

curl -Lo amazon-ec2-metadata-mock https://github.com/aws/amazon-ec2-metadata-mock/releases/download/latest/amazon-ec2-metadata-mock
sudo chmod +x amazon-ec2-metadata-mock
 ./amazon-ec2-metadata-mock
./amazon-ec2-metadata-mock: line 1: Not: command not found

Build directly from source worked

Cant emulate node draining within 2 minutes

Hi,

I've try to run the mock on my spot server with aws-node-termination-handler and I successfully received the events coming from this mock.
However my problem is that the moment I've run the mock the pods on the spot terminate immediately and the cluster-autoscaler takes time to spin up a new spot so I left with downtime.
My question is how do I set up the mock to mark the spot as terminate and the termination-handler to move the pods prior to "evicting" them from the spot.

Is this how it will reflect on real termination? if so how should I configure the termination-handler to catch the event and drain only after spinning up the new pods?

standard_init_linux.go:228: exec user process caused: exec format error

Describe the bug
Running the image from public.ecr.aws is failing whereas the image from docker.hub is not

Steps to reproduce
docker run -it --rm -p 1338:1338 public.ecr.aws/aws-ec2/amazon-ec2-metadata-mock:v1.9.2

Expected outcome

v1.9.2: Pulling from public.ecr.aws/aws-ec2/amazon-ec2-metadata-mock
9b21e7244c2b: Pull complete 
7b397a0afc4e: Pull complete 
Digest: sha256:55cc3b9fb46d7e30aec202fc8ccab5391f7f9fc7169ae7dc726aae82562d61c4
Status: Downloaded newer image for amazon/amazon-ec2-metadata-mock:v1.9.2
2021/11/18 14:08:58 Warning:  Config File "aemm-config" Not Found in "[/]"
2021/11/18 14:08:58 Initiating ec2-metadata-mock for all mocks on port 1338

Application Logs

docker run -it --rm -p 1338:1338 public.ecr.aws/aws-ec2/amazon-ec2-metadata-mock:v1.9.2
standard_init_linux.go:228: exec user process caused: exec format error

Environment

  • OS/Arch: Amazon Linux release 2 (Karoo) / 4.14.252-195.483.amzn2.x86_64

Dump all metadata to a file

Describe the feature
A concise description of the feature and desired behavior.

AL2 dumps all the metadata to a file on the instance which is useful for looking at what's available globally or for quick access without having to use HTTP (or for when the metadata endpoint is restricted).

It would be useful to be able to generate this file with ec2-metadata-mock.

$ cat  /run/cloud-init/instance-data.json
{
 "base64_encoded_keys": [],
 "ds": {
  "_doc": "EXPERIMENTAL: The structure and format of content scoped under the 'ds' key may change in subsequent releases of cloud-init.",
  "_metadata_api_version": "2016-09-02",
  "dynamic": {
   "instance-identity": {
    "document": {
     "accountId": "xxxxxxxxxxxxxxxxx",
     "architecture": "x86_64",
     "availabilityZone": "us-west-2c",
     "billingProducts": null,
     "devpayProductCodes": null,
     "imageId": "ami-03af6523db112033e",
     "instanceId": "i-019f3238ddb9db5c1",
     "instanceType": "m5.4xlarge",
     "kernelId": null,
     "marketplaceProductCodes": null,
     "pendingTime": "2022-04-27T17:56:39Z",
     "privateIp": "192.168.8.35",
     "ramdiskId": null,
     "region": "us-west-2",
     "version": "2017-09-30"
    },
    "pkcs7": [
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    ],
    "rsa2048": [
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    ],
    "signature": [
     "xxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
    ]
   }
  },
  "meta-data": {
   "ami-id": "ami-03af6523db112033e",
   "ami-launch-index": "0",
   "ami-manifest-path": "(unknown)",
   "block-device-mapping": {
    "ami": "xvda",
    "root": "/dev/xvda"
   },
   "hostname": "ip-192-168-8-35.us-west-2.compute.internal",
   "iam": {
    "info": {
     "Code": "Success",
     "InstanceProfileArn": "arn:aws:iam::xxxxxxxxxxxx:instance-profile/xxxxxxxxxxxxxxxxx",
     "InstanceProfileId": "xxxxxxxxxxxxxxxxxxxxxxxx",
     "LastUpdated": "2022-04-27T17:56:40Z"
    }
   },
   "instance-action": "none",
   "instance-id": "i-019f3238ddb9db5c1",
   "instance-type": "m5.4xlarge",
   "local-hostname": "ip-192-168-8-35.us-west-2.compute.internal",
   "local-ipv4": "192.168.8.35",
   "mac": "xxxxxxxxxxxxxxxx",
   "metrics": {
    "vhostmd": "<?xml version=\"1.0\" encoding=\"UTF-8\"?>"
   },
   "network": {
    "interfaces": {
     "macs": {
      "xxxxxxxxxxxxx": {
       "device-number": "0",
       "interface-id": "eni-xxxxxxxxxxxxxx",
       "ipv4-associations": {
        "xxxxxxxxxxxxxxx": "192.168.8.35"
       },
       "local-hostname": "ip-192-168-8-35.us-west-2.compute.internal",
       "local-ipv4s": "192.168.8.35",
       "mac": "xxxxxxxxxxxxx",
       "owner-id": "xxxxxxxxxxxxxx",
       "public-hostname": "ec2-xxxxxxxxx.us-west-2.compute.amazonaws.com",
       "public-ipv4s": "xxxxxxxxxxxxxxxxx",
       "security-group-ids": "xxxxxxxxxxxxxxxxxx",
       "security-groups": "xxxxxxxxxxxxxxxxxxxxxxxxx",
       "subnet-id": "subnet-0e1c2770e9430751e",
       "subnet-ipv4-cidr-block": "192.168.0.0/19",
       "vpc-id": "vpc-02e676af1f39c5f08",
       "vpc-ipv4-cidr-block": "192.168.0.0/16",
       "vpc-ipv4-cidr-blocks": "192.168.0.0/16"
      }
     }
    }
   },
   "placement": {
    "availability-zone": "us-west-2c"
   },
   "profile": "default-hvm",
   "public-hostname": "ec2-xxxxxxxxxxxxxxx.us-west-2.compute.amazonaws.com",
   "public-ipv4": "xxxxxxxxxxxx,
   "reservation-id": "r-067e0510e77dcf3d6",
   "security-groups": "xxxxxxxxxxxxxxxx",
   "services": {
    "domain": "amazonaws.com",
    "partition": "aws"
   }
  }
 },
 "sensitive_keys": [],
 "v1": {
  "_beta_keys": [
   "subplatform"
  ],
  "availability-zone": "us-west-2c",
  "availability_zone": "us-west-2c",
  "cloud-name": "aws",
  "cloud_name": "aws",
  "instance-id": "i-019f3238ddb9db5c1",
  "instance_id": "i-019f3238ddb9db5c1",
  "local-hostname": "ip-192-168-8-35",
  "local_hostname": "ip-192-168-8-35",
  "platform": "ec2",
  "public_ssh_keys": [],
  "region": "us-west-2",
  "subplatform": "metadata (http://169.254.169.254)"
 }
}

Is the feature request related to a problem?
A description of what the problem is. For example: I'm frustrated when [...]

It may be desirable to rely on this file instead of using an HTTP client to receive metadata for various reasons. So making it easier to test with this file is useful.

Describe alternatives you've considered
A description of any alternative solutions or features you've considered.

Could construct this manually, but it's a pain.

Missing EC2ws header

Describe the bug
Server header is missing - EC2ws

Steps to reproduce
GET any endpoint and look at the header.

Expected outcome
It contains the header.

Similar to this issue from another project

jtblin/aws-mock-metadata#3

[feature request] Watch config file for changes and reload

Describe the feature
When a config file is set on the command line, provide the ability watch the config file for changes and automatically reload the values without restarting the mock endpoint. In EC2 today several values changes over time when you retrieve data from the endpoints. This will allow testing when values changes similar to in AWS.

Is the feature request related to a problem?
The metadata endpoints can not be reloaded without a restart of the application when the config file is changed. Allowing values to change will align closer to AWS where certain values can change over time from the host.

Describe alternatives you've considered

Changing the config file and then exiting and restarting the mock service.

[bug] cannot add a new tag using config overrides

Describe the bug
A concise description of what the bug is.

I am trying to add a new tag by using the config override option as follows:

ec2-overrides.json

{
  "paths": {
    "tags-instance-supercooltest": "/latest/meta-data/tags/instance/supercooltest"
  },
  "metadata": {
    "values": {
      "tags-instance-supercooltest": "supercoolvalue"
    }
  }
}

However when i hit http://localhost:1338/latest/meta-data/tags/instance i still only see:

Name
Test

which is the default behavior

Steps to reproduce
create a .json file as specified above and use that file with the -c flag:

ec2-metadata-mock -c /path/to/file/ec2-overrides.json

then hit the endpoint that returns all tags: http://localhost:1338/latest/meta-data/tags/instance

Expected outcome
A concise description of what you expected to happen.

I would expect a new tag to be added to the mock data when hitting /latest/meta-data/tags/instance so the response would look like:

Name
Test
Supercooltest

and then hitting /latest/meta-data/tags/instance/Supercooltest I would receive supercoolvalue as the response

I know that my override file is being used as i am able to change the ami-id using my .json file

Environment

  • AEMM Version: 1.11.2
  • OS/Arch: macOS Ventura 13.2.1 (M1 Chip)
  • Installation method: Brew

Problems implementing the tools without helm

Environment
Kubernetes:
cli: Major:"1", Minor:"18", GitVersion:"v1.18.3"
server: Major:"1", Minor:"16+"

Tool:
amazon-ec2-metadata-mock:v0.9.4
Steps to reproduce it
  1. Download yaml file: https://github.com/aws/amazon-ec2-metadata-mock/releases/download/v0.9.4/all-resources.yaml
  2. Change configuration for DaemonSet as follows:
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: amazon-ec2-metadata-mock
  # namespace: kube-system
  labels:
    app.kubernetes.io/name: amazon-ec2-metadata-mock
    app.kubernetes.io/instance: amazon-ec2-metadata-mock
    app.kubernetes.io/version: "v0.9.4"
spec:
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app.kubernetes.io/name: amazon-ec2-metadata-mock
      app.kubernetes.io/instance: amazon-ec2-metadata-mock
  template:
    metadata:
      labels:
        app.kubernetes.io/name: amazon-ec2-metadata-mock
        app.kubernetes.io/instance: amazon-ec2-metadata-mock
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: "beta.kubernetes.io/os"
                operator: In
                values:
                - linux
              - key: "beta.kubernetes.io/arch"
                operator: In
                values:
                - amd64
                - arm
                - arm64
      serviceAccountName: amazon-ec2-metadata-mock-service-account
      hostNetwork: false # turn off host network to prevent undesired exposure of AEMM web server
      containers:
      - name: amazon-ec2-metadata-mock
        image: amazon/amazon-ec2-metadata-mock:v0.9.4
        imagePullPolicy: IfNotPresent
        securityContext:
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          runAsUser: 1000
          runAsGroup: 1000
          allowPrivilegeEscalation: false
        args:
          - -c /var/mocks/aemm-config.json
        volumeMounts:
          - name: mocks
            mountPath: /var/mocks
      volumes:
      - name: mocks
        configMap:
          name: aemm-config
  1. Apply all resources using kubectl apply -f ...
Observed result
2020/06/18 20:50:04 Error while attempting to apply overrides from  /var/mocks/aemm-config.json: open  /var/mocks/aemm-config.json: no such file or directory

Incorrect Content-Type response header

Describe the bug
The real http://169.254.169.254/latest/meta-data/iam/security-credentials/instant-launch endpoint returns an HTTP response with header Content-Type: text/plain but this mock docker container returns with header Content-Type: application/json. This makes the docker container non-representative of actual AWS EC2 metadata endpoint behavior, and causes problems with some libraries that expect JSON objects to be returned with Content-Type: application/json.

Steps to reproduce
On an EC2 instance:

$ export TOKEN=`curl -XPUT -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" http://169.254.169.254/latest/api/token`
$ export ROLE_NAME=`curl -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/`
$ curl -s -vvv -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/iam/security-credentials/$ROLE_NAME 2>&1 | grep 'Content-Type'
< Content-Type: text/plain
$

Against this docker container running at localhost:1339:

$ export TOKEN=`curl -XPUT -H "X-aws-ec2-metadata-token-ttl-seconds: 21600" http://localhost:1339/latest/api/token`
$ export ROLE_NAME=`curl -H "X-aws-ec2-metadata-token: $TOKEN" http://localhost:1339/latest/meta-data/iam/security-credentials/`
$  curl -s -vvv -H "X-aws-ec2-metadata-token: $TOKEN" http://localhost:1339/latest/meta-data/iam/security-credentials/$ROLE_NAME 2>&1 | grep 'Content-Type'
< Content-Type: application/json
$

Expected outcome
The second sequence of curl requests above should result in Content-Type: text/plain instead of Content-Type: application/json

Environment

  • AEMM Version: docker container aws-ec2/amazon-ec2-metadata-mock:v1.11.2
  • OS/Arch: Mac OS X
  • Installation method: docker run

flags: -p 1339 -I -c /aemm-config-overrides.json

And that file's contents:

{
  "metadata": {
    "paths": {
      "placement-availability-zone": "/latest/meta-data/placement/availability-zone"
    },
    "values": {
      "placement-availability-zone": "us-west-1c"
    }
  }
}

/latest/user-data ?

Any reason why userdata isn't supported? Or are pull-requests welcome for this type of thing?

IAM credentials should have realistic values

Describe the bug
IAM security credentials do not contain realistic values for AccessKeyId and SecretAccessKey:

  • AccessKeyId is missing the AKIA prefix and is too short.
  • SecretAccessKey is too short

See https://github.com/aws/amazon-ec2-metadata-mock/blob/main/pkg/config/defaults/aemm-metadata-default-values.json#L135

Steps to reproduce
GET /latest/meta-data/iam/security-credentials/baskinc-role

Expected outcome

{
  "Code": "Success",
  "LastUpdated": "2020-04-02T18:50:40Z",
  "Type": "AWS-HMAC",
  "AccessKeyId": "AKIA1234567890ABCDEF",
  "SecretAccessKey": "v/12345678901abcdefghijklmnopqrstuvwxyzx",
  "Token": "TEST92test48TEST+y6RpoTEST92test48TEST/8oWVAiBqTEsT5Ky7ty2tEStxC1T==",
  "Expiration": "2020-04-02T00:49:51Z"
}

Application Logs
N/A

Environment

  • AEMM Version: v1.11.2
  • OS/Arch: linux/amd64
  • Installation method: Docker

Programmatic use in Go tests

Describe the feature

I'm working on IMDS support for a project of mine, and I need a relatively faithful IMDS API to test it again. This project seems like it'll fit the bill, but running a CLI for the purpose seems overkill. I'd much rather have a simple test HTTP server I can fire up at the beginning of my unit tests.

I looked briefly at the code and it seems like there's a lot of setup involved. I naïvely tried this, but it's obviously not enough:

	cfg := config.Config{
		Server: config.Server{
			HostName: "localhost",
			Port:     "1338",
		},
	}
	go func() {
		root.Mock(cfg)
	}()

There seems to be a lot of global variables, which make it difficult for this kind of usage. It's probably not a huge amount of effort to refactor to be more modular, though.

Mostly I'm filing this issue to see if there's interest in making the necessary changes - otherwise I'll adapt!

Is the feature request related to a problem?

Describe alternatives you've considered

Installing the binary and using os.Exec to run it in the background - but there are downsides to this.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.