I am running docker-container on Amazon EC2. Currently I have added AWS Credentials to Dockerfile. Could you please let me know the best way to do this?
A lot has changed in Docker since this question was asked, so here's an attempt at an updated answer.
First, specifically with AWS credentials on containers already running inside of the cloud, using IAM roles as Vor suggests is a really good option. If you can do that, then add one more plus one to his answer and skip the rest of this.
Once you start running things outside of the cloud, or have a different type of secret, there are two key places that I recommend against storing secrets:
Environment variables: when these are defined on a container, every process inside the container has access to them, they are visible via /proc, apps may dump their environment to stdout where it gets stored in the logs, and most importantly, they appear in clear text when you inspect the container.
In the image itself: images often get pushed to registries where many users have pull access, sometimes without any credentials required to pull the image. Even if you delete the secret from one layer, the image can be disassembled with common Linux utilities like tar and the secret can be found from the step where it was first added to the image.
So what other options are there for secrets in Docker containers?
Option A: If you need this secret only during the build of your image, cannot use the secret before the build starts, and do not have access to BuildKit yet, then a multi-stage build is a best of the bad options. You would add the secret to the initial stages of the build, use it there, and then copy the output of that stage without the secret to your release stage, and only push that release stage to the registry servers. This secret is still in the image cache on the build server, so I tend to use this only as a last resort.
Option B: Also during build time, if you can use BuildKit which was released in 18.09, there are currently experimental features to allow the injection of secrets as a volume mount for a single RUN line. That mount does not get written to the image layers, so you can access the secret during build without worrying it will be pushed to a public registry server. The resulting Dockerfile looks like:
# syntax = docker/dockerfile:experimental
FROM python:3
RUN pip install awscli
RUN --mount=type=secret,id=aws,target=/root/.aws/credentials aws s3 cp s3://... ...
And you build it with a command in 18.09 or newer like:
DOCKER_BUILDKIT=1 docker build -t your_image --secret id=aws,src=$HOME/.aws/credentials .
Option C: At runtime on a single node, without Swarm Mode or other orchestration, you can mount the credentials as a read only volume. Access to this credential requires the same access that you would have outside of docker to the same credentials file, so it's no better or worse than the scenario without docker. Most importantly, the contents of this file should not be visible when you inspect the container, view the logs, or push the image to a registry server, since the volume is outside of that in every scenario. This does require that you copy your credentials on the docker host, separate from the deploy of the container. (Note, anyone with the ability to run containers on that host can view your credential since access to the docker API is root on the host and root can view the files of any user. If you don't trust users with root on the host, then don't give them docker API access.)
For a docker run, this looks like:
docker run -v $HOME/.aws/credentials:/home/app/.aws/credentials:ro your_image
Or for a compose file, you'd have:
version: '3'
services:
app:
image: your_image
volumes:
- $HOME/.aws/credentials:/home/app/.aws/credentials:ro
Option D: With orchestration tools like Swarm Mode and Kubernetes, we now have secrets support that's better than a volume. With Swarm Mode, the file is encrypted on the manager filesystem (though the decryption key is often there too, allowing the manager to be restarted without an admin entering a decrypt key). More importantly, the secret is only sent to the workers that need the secret (running a container with that secret), it is only stored in memory on the worker, never disk, and it is injected as a file into the container with a tmpfs mount. Users on the host outside of swarm cannot mount that secret directly into their own container, however, with open access to the docker API, they could extract the secret from a running container on the node, so again, limit who has this access to the API. From compose, this secret injection looks like:
version: '3.7'
secrets:
aws_creds:
external: true
services:
app:
image: your_image
secrets:
- source: aws_creds
target: /home/user/.aws/credentials
uid: '1000'
gid: '1000'
mode: 0700
You turn on swarm mode with docker swarm init for a single node, then follow the directions for adding additional nodes. You can create the secret externally with docker secret create aws_creds $HOME/.aws/credentials. And you deploy the compose file with docker stack deploy -c docker-compose.yml stack_name.
I often version my secrets using a script from: https://github.com/sudo-bmitch/docker-config-update
Option E: Other tools exist to manage secrets, and my favorite is Vault because it gives the ability to create time limited secrets that automatically expire. Every application then gets its own set of tokens to request secrets, and those tokens give them the ability to request those time limited secrets for as long as they can reach the vault server. That reduces the risk if a secret is ever taken out of your network since it will either not work or be quick to expire. The functionality specific to AWS for Vault is documented at https://www.vaultproject.io/docs/secrets/aws/index.html
The best way is to use IAM Role and do not deal with credentials at all. (see http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html )
Credentials could be retrieved from http://169.254.169.254..... Since this is a private ip address, it could be accessible only from EC2 instances.
All modern AWS client libraries "know" how to fetch, refresh and use credentials from there. So in most cases you don't even need to know about it. Just run ec2 with correct IAM role and you good to go.
As an option you can pass them at the runtime as environment variables ( i.e docker run -e AWS_ACCESS_KEY_ID=xyz -e AWS_SECRET_ACCESS_KEY=aaa myimage)
You can access these environment variables by running printenv at the terminal.
Yet another approach is to create temporary read-only volume in docker-compose.yaml. AWS CLI and SDK (like boto3 or AWS SDK for Java etc.) are looking for default profile in ~/.aws/credentials file.
If you want to use other profiles, you just need also to export AWS_PROFILE variable before running docker-compose command.
export AWS_PROFILE=some_other_profile_name
version: '3'
services:
service-name:
image: docker-image-name:latest
environment:
- AWS_PROFILE=${AWS_PROFILE}
volumes:
- ~/.aws/:/root/.aws:ro
In this example, I used root user on docker. If you are using other user, just change /root/.aws to user home directory.
:ro - stands for read-only docker volume
It is very helpful when you have multiple profiles in ~/.aws/credentials file and you are also using MFA. Also helpful when you want to locally test docker-container before deploying it on ECS on which you have IAM Roles, but locally you don't.
Another approach is to pass the keys from the host machine to the docker container. You may add the following lines to the docker-compose file.
services:
web:
build: .
environment:
- AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
- AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
- AWS_DEFAULT_REGION=${AWS_DEFAULT_REGION}
The following one-liner works for me even when my credentials are set up by aws-okta or saml2aws:
$ docker run -v$HOME/.aws:/root/.aws:ro \
-e AWS_ACCESS_KEY_ID \
-e AWS_CA_BUNDLE \
-e AWS_CLI_FILE_ENCODING \
-e AWS_CONFIG_FILE \
-e AWS_DEFAULT_OUTPUT \
-e AWS_DEFAULT_REGION \
-e AWS_PAGER \
-e AWS_PROFILE \
-e AWS_ROLE_SESSION_NAME \
-e AWS_SECRET_ACCESS_KEY \
-e AWS_SESSION_TOKEN \
-e AWS_SHARED_CREDENTIALS_FILE \
-e AWS_STS_REGIONAL_ENDPOINTS \
amazon/aws-cli s3 ls
Please note that for advanced use cases you might need to allow rw (read-write) permissions, so omit the ro (read-only) limitation when mounting the .aws volume in -v$HOME/.aws:/root/.aws:ro
Volume mounting is noted in this thread but as of docker-compose v3.2 + you can Bind Mount.
For example, if you have a file named .aws_creds in the root of your project:
In your service for the compose file do this for volumes:
volumes:
# normal volume mount, already shown in thread
- ./.aws_creds:/root/.aws/credentials
# way 2, note this requires docker-compose v 3.2+
- type: bind
source: .aws_creds # from local
target: /root/.aws/credentials # to the container location
Using this idea, you can publicly store your docker images on docker-hub because your aws credentials will not physically be in the image...to have them associated, you must have the correct directory structure locally where the container is started (i.e. pulling from Git)
You could create ~/aws_env_creds containing:
touch ~/aws_env_creds
chmod 777 ~/aws_env_creds
vi ~/aws_env_creds
Add these value (replace the key of yours):
AWS_ACCESS_KEY_ID=AK_FAKE_KEY_88RD3PNY
AWS_SECRET_ACCESS_KEY=BividQsWW_FAKE_KEY_MuB5VAAsQNJtSxQQyDY2C
Press "esc" to save the file.
Run and test the container:
my_service:
build: .
image: my_image
env_file:
- ~/aws_env_creds
If someone still face the same issue after following the instructions mentioned in accepted answer then make sure that you are not passing environment variables from two different sources. In my case I was passing environment variables to docker run via a file and as parameters which was causing the variables passed as parameters show no effect.
So the following command did not work for me:
docker run --env-file ./env.list -e AWS_ACCESS_KEY_ID=ABCD -e AWS_SECRET_ACCESS_KEY=PQRST IMAGE_NAME:v1.0.1
Moving the aws credentials into the mentioned env.list file helped.
for php apache docker the following command works
docker run --rm -d -p 80:80 --name my-apache-php-app -v "$PWD":/var/www/html -v ~/.aws:/.aws --env AWS_PROFILE=mfa php:7.2-apache
Based on some of previous answers, I built my own as follows.
My project structure:
├── Dockerfile
├── code
│ └── main.py
├── credentials
├── docker-compose.yml
└── requirements.txt
My docker-compose.yml file:
version: "3"
services:
app:
build:
context: .
volumes:
- ./credentials:/root/.aws/credentials
- ./code:/home/app
My Docker file:
FROM python:3.8-alpine
RUN pip3 --no-cache-dir install --upgrade awscli
RUN mkdir /app
WORKDIR /home/app
CMD python main.py
I have one laravel docker container which is build with a custom nginx + php-fpm docker image.
I have deployed successfully to a k8s cluster and can access properly, also logging into the pod and running env I can see all the environment variables being set successfully from my k8s configmap
In the laravel code I read the environment variables like this:
For example at SomeController.php have the following code:
$apiCode = env('API_CODE');
// also tried like this $apiCode = getenv('API_CODE'); still not successful in fetching
My problem and this question is that the env vars are always read empty inside the php code even though inside the pod with env command I can see them properly set, somehow the php code cannot find them.
(I am not caching laravel config so that case we can exclude, also tried with the command php artisan config:clear beforehand, still same result cannot fetch the env vars within the php)
In the kubernetes definition yml I attach the configmap to env variables like below and see them defined properly inside pod:
apiVersion: apps/v1
kind: Deployment
metadata:
name: api
labels:
tier: api
spec:
replicas: 1
selector:
matchLabels:
tier: api
template:
metadata:
labels:
tier: api
spec:
containers:
- name: api
image: somenging-fpm-image:latest
ports:
- containerPort: 80
envFrom:
- configMapRef:
name: api-config-env-file
For the moment I am lost and without any idea why this might happen.
I thought initially that maybe configmap was created late after pod started (php fpm somehow process then did not pick on start the env)
To verify and exclude that case, I destroyed the pod and recreated the deployment+pod in order to use the already existing configmap, and still the result was the same php did not pick up the env vars that were present in pod
I could log into pod by kubectl exec -it [podnamehere] /bin/bash and run env there and could see properly env vars set from my configmap api-config-env-file, but the code would always have them empty not be able to read them
I encountered this problems only when there are redis or caching system.
But you already state that
(I am not caching laravel config so that case we can exclude, also tried with the command php artisan config:clear beforehand, still same result cannot fetch the env vars within the php)
So double check if you run any command like php artisan optimize. It will save the cache to redis, and the laravel application will pick the setting up from there.
Just to make sure you don't miss anything.
Try:
php artisan optimize:clear
This command will do the following:
Cached events cleared!
Compiled views cleared!
Application cache cleared!
Route cache cleared!
Configuration cache cleared!
Compiled services and packages files removed!
Caches cleared successfully!
I'm Dockerizing legacy PHP project. I would like to have Xdebug enabled in development environment and my Dockerfile copies pre-built php.ini into container.
Due to some network issues we have to have xdebug.remote_connect_back = 0 on Mac OS X (and corresponding xdebug.remote_host = docker.for.mac.localhost) and xdebug.remote_connect_back = 1 on Linux.
Is it possible to grab current OS type in Dockerfile/Docker Compose to copy php.ini corresponding to host OS?
Use volumes described here in docker-compose.yml. Create php.linux.ini and php.mac.ini in a config folder (or wherever) and map one of them to the container:
services:
php:
image: php
volumes:
- ./config/php.linux.ini:/etc/php.ini #or wherever the config is
Of course your users will have to manually change php.linux.ini for php.mac.ini, but it's a one time manual change.
That information isn't (and shouldn't) be available at image build time. The same Linux-based image could be run on native Linux, a Linux VM on Mac (and then either the Docker Machine VM or the hidden VM provided by Docker for Mac), a Linux VM on Windows, or even a Linux VM on Linux, regardless of where it was originally built.
Configuration such as host names should be provided at container run time. Environment variables are a typical way to do this, or you can use the Docker volume mechanism to push in configuration files from the host.
If your issue is purely around debugging your application, you can also set up a full development environment on your host, and only build in to your image the things you need to run it in a more production-like environment.
I decided to use Docker Compose ability of reading .env files. The whole workflow is as following:
create .env.sample file with all the lines commented (sorry, couldn't manage to correctly display commented lines):
OS=windows
OS=linux
OS=mac
ignore .env file by adding /.env line to .gitignore file
copy sample file with $ cp .env.sample .env and leave uncommented just one line corresponding to your OS
move OS-specific Xdebug-related section of php.ini into separate file with names like xdebug-mac.ini, xdebug-windows.ini, xdebug-linux.ini, etc.
add to docker-compose.yml args section to chosen service with value like - OS=${OS}
in corresponding Dockerfile add lines:
ARG OS=${OS}
COPY ./xdebug-${OS}.ini /usr/local/etc/php/conf.g/
OS value mentioned in .env will be expanded on building image time
execute $ docker-compose up -d --build to build image and start container
commit all your changes on success to let your colleagues have Xdebug set properly on any platform; don't forget to tell them make their own instance of .env file from template
Background
I'm trying to use Wercker to run my test for a PHP application. Wercker uses Docker containers to setup a test environment to execute tests in. It uses Environment Variables to expose the connection params for any connected services like MySQL and Elasticsearch. Example MYSQL_PORT_3306_TCP_ADDR = 127.0.1.1
My core Docker containers is running Ubuntu 14.04 with PHP and Apache already installed on the container.
Problem
I can't seem to access the Environment Variables via php $_SERVER or $_ENV when running via Apache. It works fine if I run the script via CLI php ./db_connect.php or if I run PHP using its build in server php -S localhost:8000. However If I try and access a page via the Apache virtual host, the Environment Variables are not available.
Progress
I have setup Apache with the mod used to allow environmental variables "I think"
sudo a2enmod env
sudo service apache2 restart
I'm trying to access the Environment Variables in my script.
$database_host = $_SERVER["MYSQL_PORT_3306_TCP_ADDR"];
$database_username = $_SERVER["MYSQL_ENV_MYSQL_USER"];
$database_password = $_SERVER["MYSQL_ENV_MYSQL_PASSWORD"];
$database_name = $_SERVER["MYSQL_ENV_MYSQL_DATABASE"];
$elasticsearch_host = $_SERVER["ELASTICSEARCH_PORT_9300_TCP_ADDR"];
I can add new variables in my .htaccess, I just don't get all the system environmental variables.
SetEnv TEST_VAR test
I have read this question How to get system environment variables into PHP while running CLI & Apache2Handler? but i'm not sure what its suggesting to do.
Question
How do I expose System Environment Variables to Apache and PHP?
If you are using php official Docker image you have to explicitly pass environment variables from Apache to PHP.
You can do something like this:
In your Dockerfile:
FROM php:7.2-apache
RUN echo 'SetEnv MYSQL_USER ${MYSQL_USER}' > /etc/apache2/conf-enabled/environment.conf
environment.conf is an arbitrary name, but it should be placed in /etc/apache2/conf-enabled/.
In docker-compose.yml:
version: '2'
services:
yourservice:
build: ./yourimage
image: yourimage
ports:
- 8080:80
volumes:
- ../html:/var/www/html
environment:
MYSQL_USER: foo
In your PHP script:
echo getenv('MYSQL_USER');
Here is the solution:
Docker will pass these to apache but you have to configure apache to make them available to PHP.
Setup the values in your local .env file
MYSQL_PORT_3306_TCP_ADDR=1234
MYSQL_ENV_MYSQL_USER=development
MYSQL_ENV_MYSQL_PASSWORD=password
Then add these as environment params in the docker-compose.yml file
version: 2
services:
web:
build: php:5.6-apache
environment:
MYSQL_PORT_3306_TCP_ADDR:${MYSQL_PORT_3306_TCP_ADDR}
MYSQL_ENV_MYSQL_USER: ${MYSQL_ENV_MYSQL_USER}
MYSQL_ENV_MYSQL_PASSWORD: ${MYSQL_ENV_MYSQL_PASSWORD}
Then to pass these to PHP set these as environment params in your Virtual Host config
<VirtualHost *:80>
ServerName some-project
ServerAdmin webmaster#localhost
DocumentRoot /var/www/some-project
# Set apache environment variables
SetEnv MYSQL_PORT_3306_TCP_ADDR ${MYSQL_PORT_3306_TCP_ADDR}
SetEnv MYSQL_ENV_MYSQL_USER ${MYSQL_ENV_MYSQL_USER}
SetEnv MYSQL_ENV_MYSQL_PASSWORD ${MYSQL_ENV_MYSQL_PASSWORD}
</VirtualHost>
These will now be available to access in PHP via the $_SERVER super global array.
<?php
echo $_SERVER['MYSQL_ENV_MYSQL_USER'];
if you're using php-fpm, you can pass env vars from OS to PHP-FPM through clear_env ini setting in a file like /path/to/php/fpm/pool.d/www.conf:
clear_env = no
it works with environment vars set via docker-compose.yml as below:
version: "..."
services:
php-fpm:
image: php:7-fpm
environment:
MY_VAR: my-value
IMPORTANT: Of course, the risk is that your PHP-FPM will get access to all OS env vars. If passing all vars is a problem, you can also pass only specific vars via www.conf or another php ini config file:
; Pass environment variables like LD_LIBRARY_PATH. All $VARIABLEs are taken from
; the current environment.
env[MY_VAR] = $MY_VAR
With docker-compose you can retrieve the operating system's environment variables set with the environment option of the docker-compose.yml file through php's $_ENV variable.
version: 2
services:
web:
build: php:5.6-apache
environment:
MYSQL_USER: "user"
MYSQL_PASSWORD: "passwd"
should give you
$_ENV['MYSQL_USER'] = user
$_ENV['MYSQL_PASSWORD'] = passwd
I'm not sure how Wercker maps environment variables to the containers, but there's this open issue that I think might help
https://github.com/wercker/wercker/issues/63
you can check get env with php command like below
php -r "echo getenv('MYSQL_USER');"
I have an Docker container running nginx and php-fpm using supervisord.
I am trying to use .ebextensions/*.config to set up environment variables.
Although the variables are set up in the container (e.g # echo $VAR prints the expected value), I can't find an easy way to make them available to PHP. IMHO I could only write a bash script to read and copy the vars to www.conf or to nginx host config as fcgi_param. But then this script will need to know which variables to copy... .
I am wondering if anyone found an easier way to do this.
I wrote bash script which will copy env vars starting with a list of prefixes to the fpm's www.conf file and baked it into my image's start.sh script.
This still won't put variables in $_ENV :( but will add them to $_SERVER and are available via getenv().
Script is here: adrian7/php-transfer-vars.sh
There are two ways to do this with any reliability. For all of the web side stuff set the environment variables in an .htaccess file. You could do this for your database connection information, for example:
# environment variables
SetEnv DBL "mysql:dbname=mydatabase;host=localhost;port=3306"
SetEnv DB_USER "root"
SetEnv DB_PASS "fruitygoodness"
Place the .htaccess file in the web root in your container. When you need the environment variables you can retrieve them with PHP's getenv().
define('DBL', getenv('DBL'));
define('USER', getenv('DB_USER'));
define('PASS', getenv('DB_PASS'));
For the PHP-CLI inside the container you would specify the environment variables in the Docker run command by specifying the option -e prior to each variable. Here is an example:
sudo docker run --name mysite -e "DBL=mysql:dbname=mydatabase;host=localhost;port=3306" -e "DB_USER=root" -e "DB_PASS=fruitgoodness" -p 80:80 -p 443:443 -P -d repo/mysite
Doing this makes the environment variables available to the container but not to the web server running in the container.