{"id":21107139,"url":"https://github.com/billtrust/iam-docker-run","last_synced_at":"2025-04-05T23:05:33.172Z","repository":{"id":55021815,"uuid":"134317247","full_name":"billtrust/iam-docker-run","owner":"billtrust","description":"Run Docker containers within the context of an AWS IAM Role, and other development workflow helpers.","archived":false,"fork":false,"pushed_at":"2024-11-20T21:17:22.000Z","size":44,"stargazers_count":58,"open_issues_count":1,"forks_count":4,"subscribers_count":3,"default_branch":"master","last_synced_at":"2025-03-29T22:11:16.599Z","etag":null,"topics":["aws-iam","development-environment","development-workflow","docker","iam-role"],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/billtrust.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.txt","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2018-05-21T19:44:53.000Z","updated_at":"2024-11-20T21:17:26.000Z","dependencies_parsed_at":"2024-12-22T15:10:39.903Z","dependency_job_id":"b0883695-30bf-47ee-9334-081257684eae","html_url":"https://github.com/billtrust/iam-docker-run","commit_stats":{"total_commits":34,"total_committers":10,"mean_commits":3.4,"dds":0.4411764705882353,"last_synced_commit":"3f951b54783a333af45e8ce149b0021e426ec0ae"},"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/billtrust%2Fiam-docker-run","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/billtrust%2Fiam-docker-run/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/billtrust%2Fiam-docker-run/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/billtrust%2Fiam-docker-run/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/billtrust","download_url":"https://codeload.github.com/billtrust/iam-docker-run/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":247411226,"owners_count":20934653,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["aws-iam","development-environment","development-workflow","docker","iam-role"],"created_at":"2024-11-20T00:36:14.154Z","updated_at":"2025-04-05T23:05:33.154Z","avatar_url":"https://github.com/billtrust.png","language":"Python","readme":"# IAM-Docker-Run\n\nRun Docker containers within the context of an AWS IAM Role, and other development workflow helpers.\n\n## Motivation\n\nThe goal is to run our application on our laptops in development in as similar environment as possible to the production environment when the application runs in ECS or EKS, which would run under the task IAM role with permissions specific to that task.\n\nA shortcut sometimes taken by developers is to execute code locally with their personal IAM user which often has very high and broad privileges.  Worse, those long lived credentials sometimes find themselves checked into source control as part of a docker-compose.yml file, etc.  IAM-Docker-Run allows you to run your containers locally within the context of the IAM role you've created for your application.  The credentials themselves are temporary, they are stored in a file in your system's temp path, and never wind up in source control.\n\nIAM-Docker-Run generates AWS temporary credentials and builds a lengthly `docker run` command line statement, echoing it as it executes it so you have transparency into the command it is running.\n\n**This is a development workflow tool, not designed to run production containers.**\n\nA related effort is [IAM-Starter](https://github.com/billtrust/iam-starter) which starts a local process (outside of Docker) in the context of an AWS IAM role.\n\n## Installation\n\n```shell\npip install iam-docker-run\n```\n\n## Basic Example Usage\n\nSay you are developing a console application using AWS resources and are in your project's root directory and want to execute your application using your latest source code and the IAM role created for your project.\n\n```shell\niam-docker-run \\\n    --image mycompany/myservice:latest \\\n    --role role-myservice-task\n```\n\nYou can alternatively specify a local AWS profile, then the container will run with the credentials given by that role.  This profile would have to exist locally in your `~/.aws/config` file, which can be created with `aws configure --profile myprofile`.\n\n```shell\niam-docker-run \\\n    --image mycompany/myservice:latest \\\n    --profile myprofile\n```\n\nOr you can specify a role and a profile.  In this case the profile provides the credentials necessary to assume the role.\n\n```shell\niam-docker-run \\\n    --image mycompany/myservice:latest \\\n    --role role-myservice-task \\\n    --profile myprofile\n```\n\n## Arguments and More Examples\n\n### Full argument list\n\nFor a full list of arguments, run `iam-docker-run -h`.\n\n### Full Entrypoint\n\nThe Docker syntax for overriding an entrypoint with anything more than one word can seem couterintuitive.  With the Docker syntax, the entrypoint can only be the first command and all arguments to that are separated out on the cmd, so if you want to run `python myapp.py --myarg test123`, then `python` is your entrypoint and the rest go on your cmd, to produce a docker run statement like:\n\n```shell\ndocker run --entrypoint python mycompany/myimage myapp.py --myarg test123\n```\n\nTo make things easier, iam-docker-run provides the `--full-entrypoint` argument, so you can use it like this:\n\n```shell\niam-docker-run \\\n    --image mycompany/myimage \\\n    --full-entrypoint \"python myapp.py --myarg test123\"\n```\n\n### Shell\n\nIf you want to debug something in the container, just add a `--shell` argument and it will override the entrypoint with `/bin/bash`.  If you wish to use an alternate shell, you can override this with the following enrivonment variable:\n\n```shell\nexport IAM_DOCKER_RUN_SHELL_COMMAND=\"/bin/sh\"\n```\n\nIt is especially convenient to use this command to add to the end of any existing set of arguments.  It will override both the default ENTRYPOINT defined in the Dockerfile as well as the `--full-entrypoint` argument.\n\n```shell\n# for example, --shell will take precedence over --full-entrypoint\niam-docker-run \\\n    --image mycompany/myimage \\\n    --full-entrypoint \"python myapp.py --myarg test123\" \\\n    --shell # let me jump in real quick without modifying the rest of my args\n```\n\n### Custom environment variables file\n\nIf you have environment variables you want passed to Docker via `docker run --env-file`, with iam-docker-run you would use `--custom-env-file`.  The reason for this is that iam-docker-run is already using a file to pass into Docker with the environment variables for the AWS temporary credentials, so if you have environment variables to add to that, specify a `--custom-env-file` and that will be concatenated to the env file created by iam-docker-run.\n\nDefault behavior is to look for a file called `iam-docker-run.env`.  If this file is not found it is silently ignored.  This is helpful if you have an environment variable such as `AWS_ENV=dev` which you want loaded each time without specifying this argument.  Hopefully the rest of your variables are loaded into the environment from a remote configuration store such as AWS SSM Parameter Store.  If you need help with this see [ssm-starter](https://github.com/billtrust/ssm-starter).\n\n### Custom environment arguments\n\nAdditionally you can pass environment variables by `-e` or `--envvar`, which is passthrough to the `docker -e` argument.  These are additive with the custom environment variables file.\n\n### Foreground / background\n\nAs the main use case is a development workflow, by default the container runs in the foreground.  To run in the background, specify `--detached`, which maps to the `docker run -d` command.  To interact with the terminal, specify `--interactive`, which maps to `docker run -it`.\n\n### Source code volume mount by arguments (developer workflow)\n\nThe `--host-source-path` and `--container-source-path` arguments are designed to make it easy to mount your source code into the container when using Docker in a developer workflow where you make changes in your IDE on your host computer and want that source code immediately inserted into the container.  The `--host-source-path` argument can be relative.  In prior versions of IAM-Docker-Run the source code mount was automatic and required the `--no-volume` argument to prevent mounting it.  This automatic mount behavior has been removed however these arguments will remain for backward compatibility.\n\n```shell\niam-docker-run \\\n    --image mycompany/myservice \\\n    --role role-myservice-task \\\n    --host-source-path ./mysource \\\n    --container-source-path /myapp\n```\n\n### Additional volume mounts\n\nYou can mount additional volumes by `-v` or `--volume`, which is passthrough to the `docker -v` argument.  These are additive with the source code volume mount (if specified) and the docker in docker mount.\n\n### Assigning additional capabilities\n\nYou can assign additional capabilities to a container by using `--cap-add`, which is passed through to the `docker --cap-add` argument.\n\n### Overcoming SELinux with volume mounts\n\nIf you are running SELinux and experience permission denied issues when mounting volumes, specify the `--selinux` argument, which will alter the dockr run volume mount argument so that the volume is readable.\n\n### Enable Docker in Docker\n\nIf you want to enable Docker in Docker, you can mount the Docker socket by adding the `--mount-docker` argument.  If you then install Docker in the container with the below script and use the Docker CLI from within the container.\n\n```shell\n# install the docker client\ncurl -fsSL get.docker.com -o get-docker.sh\nsh get-docker.sh\n```\n\n### Adding a portmap\n\nYou can use `--portmap` or `-p`, which is a direct match to the `docker run -p` argument, for example:\n\n```shell\niam-docker-run \\\n    --image mycompany/myservice \\\n    --role role-myservice-task \\\n    --portmap 30000:3000\n```\n\nThe `--portmap 30000:3000` argument in this example would take a HTTP server listening in the container on port 3000 and maps it to port 30000 on your laptop.\n\nNote that you can use multiple portmaps as follows:\n\n```shell\niam-docker-run \\\n    --image mycompany/myservice \\\n    --role role-myservice-task \\\n    -p 4430:443 \\\n    -p 8080:80\n```\n\n### Region\n\nIf `--region` is provided that will take precidence, otherwise iam-docker-run will look for your region in AWS_REGION or AWS_DEFAULT_REGION environment variables.  If none are provided it will default to us-east-1.\n\n## Container Name Tempfile\n\nIAM-Docker-Run generates a random container name if the --name arg is not supplied.  If this container name is needed for anything downstream such as the code debugging inside the container feature of VSCode, the container name needs to be discoverable.  IAM-Docker-Run enables this by generating a file which contains the name of the container and writes it in a pre-determined location.\n\nThe location of this file follows the:\n`/temp/\u003clast directory name of pwd\u003e/_container_name.txt`\n\nYou can override the first part of the prefix with the following environment variable:\n\n```shell\nexport IAM_DOCKER_RUN_CONTAINER_NAME_PATH_PREFIX=/tmp/somewhere/else\n```\n\nOr you can disable this entirely by setting:\n\n```shell\nexport IAM_DOCKER_RUN_DISABLE_CONTAINER_NAME_TEMPFILE=true\n```\n\n## Shortcut\n\nAn alternate way to invoke iam-docker-run on the command line is to use the alias `idr`.  Just less typing.\n\n```shell\nidr --image busybox --role myrole\n```\n\n## Example CI workflow\n\nThe second use case for iam-docker-run is for running tests from continuous integration.  \n\n```shell\niam-docker-run \\\n    --image mycompany/myimage \\\n    --role role-myservice-task \\\n    --full-entrypoint \"/bin/bash /tests/run-integration-test.sh\" \\\n    --profile jenkins\n```\n\n## Verbose debugging\n\nTo turn on verbose output for debugging, set the `--verbose` argument.\n\n## Temporary Credentials Expire Within 1 Hour\n\nA goal of this project was to be as easy as possible for developers to use and to allow the greatest portability.  To that end, the temporary AWS credentials are generated just once before the container starts, rather than requiring a more complex setup where an additional container would run all the time and regenerate credentials.  When the temp credentials expire (the STS max of 1 hour), the application will start experiencing expired credential exceptions.  For this among other reasons is why you would not use this tool in any environment other than local development or in your build/CI/CD workflow where usage periods are short and the container can be restarted easily and often.\n\nNote: While the STS temporary credentials maximum was recently raised to 12 hours, if you are already in the context of an IAM role which is then assuming another role, the limit in this case remains to be 1 hour.\n\n## Testing\n\nRun the automated script cli tests:\n\n```shell\npip install --user nose scripttest\npython setup.py install --user\nexport AWS_REGION=us-east-1\n# set AWS_PROFILE to a valid profile name which can assume roles\nexport AWS_PROFILE=dev\nnosetests -v --exe -w ./test\n```\n\nTesting the use case of a role being supplied without a profile, using the credentials in the environment, is difficult to test an a generic automated way.  For now, the following manual steps can test this condition.\n\n```shell\n# set ROLE_ARN_FOR_LOCAL_CREDS to a role which can list s3 buckets\nexport ROLE_ARN_FOR_LOCAL_CREDS=arn:aws:iam::123456789012:role/my-role\n# set AWS_PROFILE to a valid profile name which can assume the ROLE_ARN\nexport AWS_PROFILE=dev\nexport ROLE_NAME_FOR_CONTAINER=role-ops-developers\n\naws sts assume-role \\\n    --role-arn $ROLE_ARN_FOR_LOCAL_CREDS \\\n    --role-session-name testing \\\n    --profile $AWS_PROFILE\n\n# put credentials in the environment\nexport AWS_ACCESS_KEY_ID=fromabove\nexport AWS_SECRET_ACCESS_KEY=fromabove\nexport AWS_SESSION_TOKEN=fromabove\n\niam-docker-run \\\n    --role $ROLE_NAME_FOR_CONTAINER \\\n    --image mesosphere/aws-cli:latest --full-entrypoint \"aws s3 ls\"\n\n# command should succeed with a listing of s3 buckets\n```\n\n## Publishing Updates to PyPi\n\nFor the maintainer - to publish an updated version of Iam-Docker-Run, increment the version number in iam_docker_run.py and run the following:\n\n```shell\ndocker build -f ./Dockerfile.buildenv -t billtrust/iam-docker-run:build .\ndocker run --rm -it --entrypoint make billtrust/iam-docker-run:build publish\n```\n\nAt the prompts, enter the username and password to the Billtrust pypi.org repo.\n\n## License\n\nMIT License\n\nCopyright (c) 2018 Factor Systems Inc.\n\nPermission is hereby granted, free of charge, to any person obtaining a copy\nof this software and associated documentation files (the \"Software\"), to deal\nin the Software without restriction, including without limitation the rights\nto use, copy, modify, merge, publish, distribute, sublicense, and/or sell\ncopies of the Software, and to permit persons to whom the Software is\nfurnished to do so, subject to the following conditions:\n\nThe above copyright notice and this permission notice shall be included in all\ncopies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \"AS IS\", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR\nIMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,\nFITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE\nAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER\nLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,\nOUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE\nSOFTWARE.\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbilltrust%2Fiam-docker-run","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fbilltrust%2Fiam-docker-run","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fbilltrust%2Fiam-docker-run/lists"}