natearn / 12-factor-docker-example Goto Github PK

Each services should be secured, demanding some form of authorization in order to interact with it. In order to obtain that authorization at runtime, in a secure way, services will use hashicorp Vault. The service should exchange an authentication credential (which will be provided through the config) with the secrets service for an authorization credential for a specific service.

The scope and nature of the granted authorization are to be determined. At this time, I am not certain of the expectations or limitations of vault. This secrets solution should be easily replaced, in case the deployment environment offers an integrated solution, but the general authorization pattern should still be followed:

• credentials are not passed through the config (env vars)
• credentials are not stored in the build
• credentials are obtained at runtime
• credentials are obtained in the same way across all environments (no env-specific app code)

TODO:

1. Set up the Vault dev server in the dev environment (docker-compose) as the secrets.
2. Configure the Vault dev server to provide a database username and password.
3. Update the api and database services to connect using the credentials provided by the secrets service.
4. Configure the Vault dev server to protect the database credentials with an authentication mechanism.
5. Configure the api service to authenticate with the secrets service to facilitate the database connection.

This a follow-up to issue #2.

In order for this example app to exercise this architecture, it needs to use the database service. I think the easiest possible way to do this is to put categories into a table.

It's probably best to do this after setting up the secrets service.

I predict this involves:

• Determining how to run the app from the docker image, or failing that, installing the app locally.
• Determining how to use the app to create a test.
• Creating and saving a test.
• Making the saved test accessible to the cypress service in the test stack.

A cypress test is part of a collection which must be provided to the cypress service upon container startup. Using a host-mount sounds tempting here, but I doubt it will work for other environments; try to find something that works across the board.

Please update the README with instructions on how to repeat this process, especially if any part of it is domain-specific or unintuitive.

Following my own advice, and the advice of the 12 factor guideline. All image versions should be static, such that the containers do not change unintentionally between deployments.

It might be enough to lookup the latest versions of the images on docker hub, and use that.

The primary role of these Dockerfiles is to build images for production. Ideally, these images can also be used as-is for development, but I don't expect that to necessarily be satisfiable.

Improvements:

• Replace the server with something that claims to be intended for running in a production environment.
• Run the server as an unprivileged user (not root).
• Separate dependencies from source code to speed up builds.

Considerations:

• A server that can be configured to use hot-reloading on source file changes.
• A server that can be configured to produce logs that are valuable for development and debugging.

In a real-world situation, these would be the stars of the show. But right now they are more of an inconvenience. They don't have to be pretty, they don't have to be useful, but they do need to exercise the architecture to illustrate how this all works together.

I predict this will require the assignee to:

• Choose only one interaction with one service (example: login).
• Determine how to mountebank imposter for that interaction on that service. The imposter should use a "proxy" stub, from a saved recording of the interaction.
• Determine how to supply that saved stub to the mocks service. Ensure that it can be repeated on other environments (don't use a host-binding).

The Goal here is to generate a working example of a record/replay service imposter. It's important that we can capture real interactions and reuse them to enable offline end-to-end tests. A test environment should not access external resources, and in some environments, may not be able to. Recordings must then be generated in a separate "privileged" execution mode.