[lexik/jwt-authentication-bundle] gitignore JWT keys

[teohhanhui]

Q	A
License	MIT

Fixes #84

[javiereguiluz]

Even if this proposal is "the right thing" to avoid committing sensitive data to the repo, I think the fix is not correct. The etc/ dir (or config/ if we finally rename it) should be committed entirely. Now that we're getting rid of the parameters.yml + parameters.yml.dist files, it's time to simplify things committing the etc/ dir entirely and putting all the sensitive credentials in the .env file.

[teohhanhui]

putting all the sensitive credentials in the .env file

From moby/moby#13490:

• Environment Variables. Probably the most used, because it's part of the "12 factor app". Environment variables are discouraged, because they are;
  • Accessible by any proces in the container, thus easily "leaked"
  • Preserved in intermediate layers of an image, and visible in docker inspect
  • Shared with any container linked to the container

Docker now has a "secrets" feature (Swarm Mode only) which exposes each piece of sensitive data as files under the /run/secrets directory.

[dunglas]

Maybe can we just move the JWT keys in var/jwt?

[sroze]

Yes, I think that this should definitely live in var if they are committed to the code repository.

[sstok]

If the JWT keys are generated for each application separate (like secret), then 👍

[chalasr]

Not sure about var. I use it myself and not so long ago someone told me "But var/ is about storage, temporary data, cache, logs... Removing keys just breaks the setup", and I think he is right.

[dunglas]

But the keys should be different on each instance of an app. So they shouldn't be in etc/. Imo we should have a directory to store such sensitive informations (maybe secret/?).

Btw, I'm implementing a mechanism similar to env() but to read files containing secret data at runtime and inject them in the container as parameters (for instance, to use Docker secrets). It would be nice to have a directory to store such data (for those not using Docker).

[teohhanhui]

I disagree about using var. Please see the relevant FHS section: http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE31

etc is the correct location.

[teohhanhui]

Since etc has been renamed to config, I agree with @dunglas that we should put it under secrets/jwt.

Will update the PR.

[dunglas]

I've almost finished secrets support for the DI component. It just needs some polish (probably when I'll be back from vacation).

[fabpot]

Shoudn't it be %PROJECT_DIR%/secrets/jwt/...

[teohhanhui]

No, unless we want to support storing the key pair outside of the project directory? (Out of scope for this PR anyway...)

[teohhanhui]

But if we go ahead with this, we should probably add a secrets-dir option in Flex?

[javiereguiluz]

I agree with Fabien. This looks really strange. It should be %CONFIG_DIR%/secrets/jwt/... or %PROJECT_DIR%/secrets/jwt/...

[teohhanhui]

%CONFIG_DIR% resolves to config.
%PROJECT_DIR% resolves to the full path of the project directory.

What we might want to add is a %SECRETS_DIR% which resolves to secrets. But I still find it weird to see a %SECRETS_DIR% in an environment variable... I think the resolving should happen when Flex updates the .env (and .env.dist) files. oh wait it already does...

[teohhanhui]

symfony/symfony#23901 introduced the file prefix for %env(...)% processing.

[dunglas]

@javiereguiluz managing secret's encryption at this level looks like a bad idea to me. There are already plenty dedicated tools to do it like Docker and Kubernetes. IMO the best thing to to is to make it easy to use them in Symfony (and it's achieved with symfony/symfony#23901), not to reinvent the wheel.

I'm 👍 to introduce a new secrets directory and store things like JWT keys and Doctrine passwords in it (and retrieve them with symfony/symfony#23901).

[sroze]

The risk of the secrets directory is that people would be tempted to directly commit their credentials in the code repository... You use the example of Docker/Kubernetes and the secrets management is exactly meant to prevent people to add their secrets within the Docker image directly. As long as we give a very clear documentation that these secrets have to be development secrets and overwritten by production secrets while deploying production, then I'm 👍 with such secrets directory.

[teohhanhui]

Adding an empty directory with a .gitignore which ignores everything else should help.

[dunglas]

We can add this directory to the .gitignore file.

[sroze]

Not convinced about that the DX with this directory in the .gitignore as it means you don't have a working development environment directly after cloning a project anymore. Even if our official recipes could generate development secrets, I'm not convinced about user secrets.

[dunglas]

You can ignore the content of the directory while keeping it in the version system.

[teohhanhui]

Secrets should never be checked in.

[sroze]

Secrets should never be checked in.

This is not true. Production secrets should not be checked in. Development secrets should be checked in, so as a developer, I don't have to pull secrets from anywhere else to have a development environment working.

[teohhanhui]

Development secrets should be checked in, so as a developer, I don't have to pull secrets from anywhere else to have a development environment working.

I disagree. But we can already see this is a never-ending discussion.

[nicolas-grekas]

I'm closing as the PR is old, and Makefile have been removed.
Please resubmit if you think we still need to improve.