IAM-Docker-Run
==============
Run Docker containers within the context of an AWS IAM Role, and other
development workflow helpers.
Motivation
----------
The 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.
A 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.
IAM-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.
**This is a development workflow tool, not designed to run production
containers.**
A 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.
Installation
------------
.. code:: shell
pip install iam-docker-run
Basic Example Usage
-------------------
Say 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.
.. code:: shell
iam-docker-run \
--image mycompany/myservice:latest \
--role role-myservice-task
You 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``.
.. code:: shell
iam-docker-run \
--image mycompany/myservice:latest \
--profile myprofile
Or you can specify a role and a profile. In this case the profile
provides the credentials necessary to assume the role.
.. code:: shell
iam-docker-run \
--image mycompany/myservice:latest \
--role role-myservice-task \
--profile myprofile
Arguments and More Examples
---------------------------
Full argument list
~~~~~~~~~~~~~~~~~~
For a full list of arguments, run ``iam-docker-run -h``.
Full Entrypoint
~~~~~~~~~~~~~~~
The 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:
.. code:: shell
docker run --entrypoint python mycompany/myimage myapp.py --myarg test123
To make things easier, iam-docker-run provides the ``--full-entrypoint``
argument, so you can use it like this:
.. code:: shell
iam-docker-run \
--image mycompany/myimage \
--full-entrypoint "python myapp.py --myarg test123"
Shell
~~~~~
If 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:
.. code:: shell
export IAM_DOCKER_RUN_SHELL_COMMAND="/bin/sh"
It 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.
.. code:: shell
# for example, --shell will take precedence over --full-entrypoint
iam-docker-run \
--image mycompany/myimage \
--full-entrypoint "python myapp.py --myarg test123" \
--shell # let me jump in real quick without modifying the rest of my args
Custom environment variables file
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If 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.
Default 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>`__.
Custom environment arguments
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Additionally 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.
Foreground / background
~~~~~~~~~~~~~~~~~~~~~~~
As 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``.
Source code volume mount by arguments (developer workflow)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The ``--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.
.. code:: shell
iam-docker-run \
--image mycompany/myservice \
--role role-myservice-task \
--host-source-path ./mysource \
--container-source-path /myapp
Additional volume mounts
~~~~~~~~~~~~~~~~~~~~~~~~
You 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.
Assigning additional capabilities
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can assign additional capabilities to a container by using
``--cap-add``, which is passed through to the ``docker --cap-add``
argument.
Overcoming SELinux with volume mounts
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If 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.
Enable Docker in Docker
~~~~~~~~~~~~~~~~~~~~~~~
If 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.
.. code:: shell
# install the docker client
curl -fsSL get.docker.com -o get-docker.sh
sh get-docker.sh
Adding a portmap
~~~~~~~~~~~~~~~~
You can use ``--portmap`` or ``-p``, which is a direct match to the
``docker run -p`` argument, for example:
.. code:: shell
iam-docker-run \
--image mycompany/myservice \
--role role-myservice-task \
--portmap 30000:3000
The ``--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.
Note that you can use multiple portmaps as follows:
.. code:: shell
iam-docker-run \
--image mycompany/myservice \
--role role-myservice-task \
-p 4430:443 \
-p 8080:80
Region
~~~~~~
If ``--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.
Container Name Tempfile
-----------------------
IAM-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.
The location of this file follows the:
``/temp/<last directory name of pwd>/_container_name.txt``
You can override the first part of the prefix with the following
environment variable:
.. code:: shell
export IAM_DOCKER_RUN_CONTAINER_NAME_PATH_PREFIX=/tmp/somewhere/else
Or you can disable this entirely by setting:
.. code:: shell
export IAM_DOCKER_RUN_DISABLE_CONTAINER_NAME_TEMPFILE=true
Shortcut
--------
An alternate way to invoke iam-docker-run on the command line is to use
the alias ``idr``. Just less typing.
.. code:: shell
idr --image busybox --role myrole
Example CI workflow
-------------------
The second use case for iam-docker-run is for running tests from
continuous integration.
.. code:: shell
iam-docker-run \
--image mycompany/myimage \
--role role-myservice-task \
--full-entrypoint "/bin/bash /tests/run-integration-test.sh" \
--profile jenkins
Verbose debugging
-----------------
To turn on verbose output for debugging, set the ``--verbose`` argument.
Temporary Credentials Expire Within 1 Hour
------------------------------------------
A 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.
Note: 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.
Testing
-------
Run the automated script cli tests:
.. code:: shell
pip install --user nose scripttest
python setup.py install --user
export AWS_REGION=us-east-1
# set AWS_PROFILE to a valid profile name which can assume roles
export AWS_PROFILE=dev
nosetests -v --exe -w ./test
Testing 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.
.. code:: shell
# set ROLE_ARN_FOR_LOCAL_CREDS to a role which can list s3 buckets
export ROLE_ARN_FOR_LOCAL_CREDS=arn:aws:iam::123456789012:role/my-role
# set AWS_PROFILE to a valid profile name which can assume the ROLE_ARN
export AWS_PROFILE=dev
export ROLE_NAME_FOR_CONTAINER=role-ops-developers
aws sts assume-role \
--role-arn $ROLE_ARN_FOR_LOCAL_CREDS \
--role-session-name testing \
--profile $AWS_PROFILE
# put credentials in the environment
export AWS_ACCESS_KEY_ID=fromabove
export AWS_SECRET_ACCESS_KEY=fromabove
export AWS_SESSION_TOKEN=fromabove
iam-docker-run \
--role $ROLE_NAME_FOR_CONTAINER \
--image mesosphere/aws-cli:latest --full-entrypoint "aws s3 ls"
# command should succeed with a listing of s3 buckets
Publishing Updates to PyPi
--------------------------
For the maintainer - to publish an updated version of Iam-Docker-Run,
increment the version number in iam_docker_run.py and run the following:
.. code:: shell
docker build -f ./Dockerfile.buildenv -t billtrust/iam-docker-run:build .
docker run --rm -it --entrypoint make billtrust/iam-docker-run:build publish
At the prompts, enter the username and password to the Billtrust
pypi.org repo.
License
-------
MIT License
Copyright (c) 2018 Factor Systems Inc.
Permission is hereby granted, free of charge, to any person obtaining a
copy of this software and associated documentation files (the
“Software”), to deal in the Software without restriction, including
without limitation the rights to use, copy, modify, merge, publish,
distribute, sublicense, and/or sell copies of the Software, and to
permit persons to whom the Software is furnished to do so, subject to
the following conditions:
The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.
IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,
TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE
SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
Raw data
{
"_id": null,
"home_page": "https://github.com/billtrust/iam-docker-run",
"name": "iam-docker-run",
"maintainer": null,
"docs_url": null,
"requires_python": null,
"maintainer_email": null,
"keywords": "aws, iam, iam-role, docker",
"author": "Doug Kerwin",
"author_email": "dwkerwin@gmail.com",
"download_url": "https://files.pythonhosted.org/packages/a2/f6/926abd5c4743d7b504f1cc1a6031310cfeff9ceed4e82dc2fd5939bafb79/iam-docker-run-0.3.9.tar.gz",
"platform": null,
"description": "IAM-Docker-Run\n==============\n\nRun Docker containers within the context of an AWS IAM Role, and other\ndevelopment workflow helpers.\n\nMotivation\n----------\n\nThe goal is to run our application on our laptops in development in as\nsimilar environment as possible to the production environment when the\napplication runs in ECS or EKS, which would run under the task IAM role\nwith permissions specific to that task.\n\nA shortcut sometimes taken by developers is to execute code locally with\ntheir personal IAM user which often has very high and broad privileges.\nWorse, those long lived credentials sometimes find themselves checked\ninto source control as part of a docker-compose.yml file, etc.\nIAM-Docker-Run allows you to run your containers locally within the\ncontext of the IAM role you\u2019ve created for your application. The\ncredentials themselves are temporary, they are stored in a file in your\nsystem\u2019s temp path, and never wind up in source control.\n\nIAM-Docker-Run generates AWS temporary credentials and builds a lengthly\n``docker run`` command line statement, echoing it as it executes it so\nyou have transparency into the command it is running.\n\n**This is a development workflow tool, not designed to run production\ncontainers.**\n\nA related effort is\n`IAM-Starter <https://github.com/billtrust/iam-starter>`__ which starts\na local process (outside of Docker) in the context of an AWS IAM role.\n\nInstallation\n------------\n\n.. code:: shell\n\n pip install iam-docker-run\n\nBasic Example Usage\n-------------------\n\nSay you are developing a console application using AWS resources and are\nin your project\u2019s root directory and want to execute your application\nusing your latest source code and the IAM role created for your project.\n\n.. code:: shell\n\n iam-docker-run \\\n --image mycompany/myservice:latest \\\n --role role-myservice-task\n\nYou can alternatively specify a local AWS profile, then the container\nwill run with the credentials given by that role. This profile would\nhave to exist locally in your ``~/.aws/config`` file, which can be\ncreated with ``aws configure --profile myprofile``.\n\n.. code:: shell\n\n iam-docker-run \\\n --image mycompany/myservice:latest \\\n --profile myprofile\n\nOr you can specify a role and a profile. In this case the profile\nprovides the credentials necessary to assume the role.\n\n.. code:: shell\n\n iam-docker-run \\\n --image mycompany/myservice:latest \\\n --role role-myservice-task \\\n --profile myprofile\n\nArguments and More Examples\n---------------------------\n\nFull argument list\n~~~~~~~~~~~~~~~~~~\n\nFor a full list of arguments, run ``iam-docker-run -h``.\n\nFull Entrypoint\n~~~~~~~~~~~~~~~\n\nThe Docker syntax for overriding an entrypoint with anything more than\none word can seem couterintuitive. With the Docker syntax, the\nentrypoint can only be the first command and all arguments to that are\nseparated out on the cmd, so if you want to run\n``python myapp.py --myarg test123``, then ``python`` is your entrypoint\nand the rest go on your cmd, to produce a docker run statement like:\n\n.. code:: shell\n\n docker run --entrypoint python mycompany/myimage myapp.py --myarg test123\n\nTo make things easier, iam-docker-run provides the ``--full-entrypoint``\nargument, so you can use it like this:\n\n.. code:: shell\n\n iam-docker-run \\\n --image mycompany/myimage \\\n --full-entrypoint \"python myapp.py --myarg test123\"\n\nShell\n~~~~~\n\nIf you want to debug something in the container, just add a ``--shell``\nargument and it will override the entrypoint with ``/bin/bash``. If you\nwish to use an alternate shell, you can override this with the following\nenrivonment variable:\n\n.. code:: shell\n\n export IAM_DOCKER_RUN_SHELL_COMMAND=\"/bin/sh\"\n\nIt is especially convenient to use this command to add to the end of any\nexisting set of arguments. It will override both the default ENTRYPOINT\ndefined in the Dockerfile as well as the ``--full-entrypoint`` argument.\n\n.. code:: shell\n\n # for example, --shell will take precedence over --full-entrypoint\n iam-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\nCustom environment variables file\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nIf you have environment variables you want passed to Docker via\n``docker run --env-file``, with iam-docker-run you would use\n``--custom-env-file``. The reason for this is that iam-docker-run is\nalready using a file to pass into Docker with the environment variables\nfor the AWS temporary credentials, so if you have environment variables\nto add to that, specify a ``--custom-env-file`` and that will be\nconcatenated to the env file created by iam-docker-run.\n\nDefault behavior is to look for a file called ``iam-docker-run.env``. If\nthis file is not found it is silently ignored. This is helpful if you\nhave an environment variable such as ``AWS_ENV=dev`` which you want\nloaded each time without specifying this argument. Hopefully the rest of\nyour variables are loaded into the environment from a remote\nconfiguration store such as AWS SSM Parameter Store. If you need help\nwith this see\n`ssm-starter <https://github.com/billtrust/ssm-starter>`__.\n\nCustom environment arguments\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nAdditionally you can pass environment variables by ``-e`` or\n``--envvar``, which is passthrough to the ``docker -e`` argument. These\nare additive with the custom environment variables file.\n\nForeground / background\n~~~~~~~~~~~~~~~~~~~~~~~\n\nAs the main use case is a development workflow, by default the container\nruns in the foreground. To run in the background, specify\n``--detached``, which maps to the ``docker run -d`` command. To interact\nwith the terminal, specify ``--interactive``, which maps to\n``docker run -it``.\n\nSource code volume mount by arguments (developer workflow)\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nThe ``--host-source-path`` and ``--container-source-path`` arguments are\ndesigned to make it easy to mount your source code into the container\nwhen using Docker in a developer workflow where you make changes in your\nIDE on your host computer and want that source code immediately inserted\ninto the container. The ``--host-source-path`` argument can be relative.\nIn prior versions of IAM-Docker-Run the source code mount was automatic\nand required the ``--no-volume`` argument to prevent mounting it. This\nautomatic mount behavior has been removed however these arguments will\nremain for backward compatibility.\n\n.. code:: shell\n\n iam-docker-run \\\n --image mycompany/myservice \\\n --role role-myservice-task \\\n --host-source-path ./mysource \\\n --container-source-path /myapp\n\nAdditional volume mounts\n~~~~~~~~~~~~~~~~~~~~~~~~\n\nYou can mount additional volumes by ``-v`` or ``--volume``, which is\npassthrough to the ``docker -v`` argument. These are additive with the\nsource code volume mount (if specified) and the docker in docker mount.\n\nAssigning additional capabilities\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nYou can assign additional capabilities to a container by using\n``--cap-add``, which is passed through to the ``docker --cap-add``\nargument.\n\nOvercoming SELinux with volume mounts\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nIf you are running SELinux and experience permission denied issues when\nmounting volumes, specify the ``--selinux`` argument, which will alter\nthe dockr run volume mount argument so that the volume is readable.\n\nEnable Docker in Docker\n~~~~~~~~~~~~~~~~~~~~~~~\n\nIf you want to enable Docker in Docker, you can mount the Docker socket\nby adding the ``--mount-docker`` argument. If you then install Docker in\nthe container with the below script and use the Docker CLI from within\nthe container.\n\n.. code:: shell\n\n # install the docker client\n curl -fsSL get.docker.com -o get-docker.sh\n sh get-docker.sh\n\nAdding a portmap\n~~~~~~~~~~~~~~~~\n\nYou can use ``--portmap`` or ``-p``, which is a direct match to the\n``docker run -p`` argument, for example:\n\n.. code:: shell\n\n iam-docker-run \\\n --image mycompany/myservice \\\n --role role-myservice-task \\\n --portmap 30000:3000\n\nThe ``--portmap 30000:3000`` argument in this example would take a HTTP\nserver listening in the container on port 3000 and maps it to port 30000\non your laptop.\n\nNote that you can use multiple portmaps as follows:\n\n.. code:: shell\n\n iam-docker-run \\\n --image mycompany/myservice \\\n --role role-myservice-task \\\n -p 4430:443 \\\n -p 8080:80\n\nRegion\n~~~~~~\n\nIf ``--region`` is provided that will take precidence, otherwise\niam-docker-run will look for your region in AWS_REGION or\nAWS_DEFAULT_REGION environment variables. If none are provided it will\ndefault to us-east-1.\n\nContainer Name Tempfile\n-----------------------\n\nIAM-Docker-Run generates a random container name if the \u2013name arg is not\nsupplied. If this container name is needed for anything downstream such\nas the code debugging inside the container feature of VSCode, the\ncontainer name needs to be discoverable. IAM-Docker-Run enables this by\ngenerating a file which contains the name of the container and writes it\nin a pre-determined location.\n\nThe location of this file follows the:\n``/temp/<last directory name of pwd>/_container_name.txt``\n\nYou can override the first part of the prefix with the following\nenvironment variable:\n\n.. code:: shell\n\n export IAM_DOCKER_RUN_CONTAINER_NAME_PATH_PREFIX=/tmp/somewhere/else\n\nOr you can disable this entirely by setting:\n\n.. code:: shell\n\n export IAM_DOCKER_RUN_DISABLE_CONTAINER_NAME_TEMPFILE=true\n\nShortcut\n--------\n\nAn alternate way to invoke iam-docker-run on the command line is to use\nthe alias ``idr``. Just less typing.\n\n.. code:: shell\n\n idr --image busybox --role myrole\n\nExample CI workflow\n-------------------\n\nThe second use case for iam-docker-run is for running tests from\ncontinuous integration.\n\n.. code:: shell\n\n iam-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\nVerbose debugging\n-----------------\n\nTo turn on verbose output for debugging, set the ``--verbose`` argument.\n\nTemporary Credentials Expire Within 1 Hour\n------------------------------------------\n\nA goal of this project was to be as easy as possible for developers to\nuse and to allow the greatest portability. To that end, the temporary\nAWS credentials are generated just once before the container starts,\nrather than requiring a more complex setup where an additional container\nwould run all the time and regenerate credentials. When the temp\ncredentials expire (the STS max of 1 hour), the application will start\nexperiencing expired credential exceptions. For this among other reasons\nis why you would not use this tool in any environment other than local\ndevelopment or in your build/CI/CD workflow where usage periods are\nshort and the container can be restarted easily and often.\n\nNote: While the STS temporary credentials maximum was recently raised to\n12 hours, if you are already in the context of an IAM role which is then\nassuming another role, the limit in this case remains to be 1 hour.\n\nTesting\n-------\n\nRun the automated script cli tests:\n\n.. code:: shell\n\n pip install --user nose scripttest\n python setup.py install --user\n export AWS_REGION=us-east-1\n # set AWS_PROFILE to a valid profile name which can assume roles\n export AWS_PROFILE=dev\n nosetests -v --exe -w ./test\n\nTesting the use case of a role being supplied without a profile, using\nthe credentials in the environment, is difficult to test an a generic\nautomated way. For now, the following manual steps can test this\ncondition.\n\n.. code:: shell\n\n # set ROLE_ARN_FOR_LOCAL_CREDS to a role which can list s3 buckets\n export 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\n export AWS_PROFILE=dev\n export ROLE_NAME_FOR_CONTAINER=role-ops-developers\n\n aws 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\n export AWS_ACCESS_KEY_ID=fromabove\n export AWS_SECRET_ACCESS_KEY=fromabove\n export AWS_SESSION_TOKEN=fromabove\n\n iam-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\nPublishing Updates to PyPi\n--------------------------\n\nFor the maintainer - to publish an updated version of Iam-Docker-Run,\nincrement the version number in iam_docker_run.py and run the following:\n\n.. code:: shell\n\n docker build -f ./Dockerfile.buildenv -t billtrust/iam-docker-run:build .\n docker run --rm -it --entrypoint make billtrust/iam-docker-run:build publish\n\nAt the prompts, enter the username and password to the Billtrust\npypi.org repo.\n\nLicense\n-------\n\nMIT License\n\nCopyright (c) 2018 Factor Systems Inc.\n\nPermission is hereby granted, free of charge, to any person obtaining a\ncopy of this software and associated documentation files (the\n\u201cSoftware\u201d), to deal in the Software without restriction, including\nwithout limitation the rights to use, copy, modify, merge, publish,\ndistribute, sublicense, and/or sell copies of the Software, and to\npermit persons to whom the Software is furnished to do so, subject to\nthe following conditions:\n\nThe above copyright notice and this permission notice shall be included\nin all copies or substantial portions of the Software.\n\nTHE SOFTWARE IS PROVIDED \u201cAS IS\u201d, WITHOUT WARRANTY OF ANY KIND, EXPRESS\nOR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF\nMERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.\nIN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY\nCLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT,\nTORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE\nSOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.\n\n\n",
"bugtrack_url": null,
"license": "MIT",
"summary": "Run Docker containers within the context of an AWS IAM Role, and other development workflow helpers.",
"version": "0.3.9",
"project_urls": {
"Homepage": "https://github.com/billtrust/iam-docker-run"
},
"split_keywords": [
"aws",
" iam",
" iam-role",
" docker"
],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "a2f6926abd5c4743d7b504f1cc1a6031310cfeff9ceed4e82dc2fd5939bafb79",
"md5": "ff51c375eec64293bc0dcf401c1b827b",
"sha256": "af68b16145fad15fe050c36593a67f991259fad0063d0e39854236be2822096d"
},
"downloads": -1,
"filename": "iam-docker-run-0.3.9.tar.gz",
"has_sig": false,
"md5_digest": "ff51c375eec64293bc0dcf401c1b827b",
"packagetype": "sdist",
"python_version": "source",
"requires_python": null,
"size": 20528,
"upload_time": "2024-11-20T21:28:12",
"upload_time_iso_8601": "2024-11-20T21:28:12.706266Z",
"url": "https://files.pythonhosted.org/packages/a2/f6/926abd5c4743d7b504f1cc1a6031310cfeff9ceed4e82dc2fd5939bafb79/iam-docker-run-0.3.9.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-11-20 21:28:12",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "billtrust",
"github_project": "iam-docker-run",
"travis_ci": false,
"coveralls": false,
"github_actions": false,
"requirements": [],
"lcname": "iam-docker-run"
}
JSON
