Use Case in PHP App

[alexw23]

Just trying to figure out the best use case to bring secrets into a PHP app.

The PHP app currently uses an .env file to pull in environment variables such as MYSQL_PASSWORD etc. So the option #1 is that we could just use consul-template to write out the .env file.

I've also considered directly reading secrets via the API each time on page load given the fast response time of Vault/Consul. This would however mean if the API is down for any reason there would be no fallback and we would need to return a 500 error.

I've also considered caching the above (using API) but now this means our secrets would be stored in Redis and kinda defeats the purpose as Vault/Consul is an awesome K/V layer.

Given that Option #2 (using API) provides an Audit trial I am leaning towards this as it also means that there is no .env lying around with secrets stored in it. Can anyone provide insights?

[narayan8291]

I faced the same use case and I read the secrets via the API every time the application is used. I have the secrets replicated in two servers (master and slave) and the application is designed in such a way that if the master goes down the slave server can be used to access these secrets.

This is a self-serve password change/reset tool and hence this would not be accessed on a day-to-day basis. Since the traffic flowing to this app is minimal, I have stuck to this method and seems to be good for the past 3 months. I think it totally depends on how critical the application is.

I would be really interested to hear about any other method that would be more optimized and safe.

[alexw23]

@narayan8291 have you noticed any issues with latency etc? If the containers are on the same host (and in the same datacenter) I'd say most calls seem to be under 2-3ms as GO is quite fast.

My mind jumps to caching - but it seems consul is as efficient as a regular K/V cache already.

[gigablah]

Why not cache it with PHP itself? Using something like php-apcu.

[narayan8291]

@alexw23 I haven't noticed any latency issues. In my case the server and the database are on the same data center.

[bweston92]

How did you guys implement this in PHP with leasing MySQL/PostgresSQL details that expire but you have a long running process?

[jippi]

I write it to a .dotenv file ( https://github.com/josegonzalez/php-dotenv ) + Consul Template or read it direclty from Vault directly using my SDK https://github.com/jippi/vault-php-sdk

[bweston92]

@jippi .env files are loaded on process start up so with a long running PHP process that would mean restarting on change. (awful) aha

[jippi]

@bweston92 that or you register a SIGHUP handler in PHP and reload the configuration? :)

I've settled with restarting the process, as its a sub-second thing, and they stagger across the platform - my procs are also very state-light, so not much lost in restarting it :)

[bweston92]

@jippi if it is mid processing something? I was thinking off adding middleware to my message handlers that would check it, just if the message process takes to long (for what ever reason) might be dead.

[jippi]

@bweston92 i SIGTERM the process, which by signal handler mark it as "please stop", and when its current job is done, it just checks that state and exit(0)and supervisord restart it right away

[bweston92]

@jippi hmm, supervisord wouldn't be in a Docker container but I believe Docker has restart policies. Thanks.

[jefferai]

@bweston92

supervisord wouldn't be in a Docker container

There's really no reason it can't be. I've done this many times...

[bweston92]

@jefferai Docker has it's own restart policy. Docker images should also normally be just one process.

https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#/run-only-one-process-per-container

[jefferai]

@bweston92 Only if you agree with and commit to Docker, Inc.'s stated principles. Many or most of the official Hub images don't even follow that particular guideline, because there is nothing to reap any zombie children of the process. (They dislike supervisord because it's considered heavyweight due to needing a Python runtime.)

Being pragmatic is always better than being dogmatic. If supervisord is something you know and love, build it into your Docker image all you want.