Skip to content

Security API

The API image runs the .NET Core app directly inside the /app folder. The same image takes care of compiling the code. It is also prepared to be cached, so some steps could be skipped if has not been changes from previous builds.

Building the image

The image must be built from the /Source folder. The Dockerfile is inside the Projects/Sequel.Security.Api/docker folder. Building the image does not require any parameters, but the appsettings.json file will not be included in the image, this must be included either by creating a new image or using a volume or secret.

docker image build -f Projects/Sequel.Security.Api/docker/Dockerfile -t security/api .

There is also a SECURITY_VERSION build argument that is useful for CD pipelines to specify which is the version that is building.

Use BuildKit to build images

It is recommended to use BuildKit instead the classic build system to improve build times of the image and take advantage of advanced cache system that brings this new system.

Preparing the app settings

As mentioned before, the image does not include an appsettings.json file, so it will always fail to run if no one is provided. The are three ways to add the settings into the container:

  1. Create a new image which adds the file inside /app (not recommended)
  2. Create a volume that maps the file into the container (-v argument in docker)
  3. Create a secret in Swarm or Kubernetes and put it in /app/appsettings.json

There are also some settings that must be set taking into account the deployment environment:

  • The InitializeSSL must be always set to false, failing to do so, will cause some troubles in the API.
  • The TrustForwardedHeaders should be set to true if the API will be behind a reverse proxy/load balancer.
  • The EnableContainerEndpoint in HealthCheckSettings must be set to true, if not, the container will be marked as unhealthy.
  • The DoubleEncodingRevert in RewriterSettings must be set to true (it is outside IIS, it must be set to true)
  • The MultitenancyDatabase context must point to the right SQL Server instance, using the right.hostname, and must use SQL Server Authentication login method (provide User Id and Password). Do the same for the Logging context.
  • Ensure internal and external URLs for the API and Authentication services are OK.
  • Check the email host to ensure it is accessible (health check may help).
  • Check the RabbitMQ host to ensure it is accessible too.
  • Check the health check (example command curl -i -H "HealthCheck-ApiKey: cdb327e2-4f20-4a55-b44a-d3b948b84356" localhost/securityapi/health)

Access to hosts services from Docker

To properly access the host services from inside a container, you must use special domains or IPs to accomplish that, and depends on the OS.

  • Docker Desktop for Windows: use docker.for.win.localhost to access host services.
  • Docker Desktop for macOS: use docker.for.mac.localhost to access host services.
  • Docker on Linux: there are several ways to do it, but probably the easiest is to point to the external IP of the host. Another way is to use the gateway of the docker network (and ensure services are listening in this network interface too).

SQL Server on Windows

This will not work unless the SQL Server has several changes applied. First, as mentioned, the API will use SQL Server Authentication method for login, instead of Windows AD. This must be enabled to allow this kind of logins. To connect to the server, will use a TCP connection, and must be enabled too.

Running the image

Once the appsettings.json file is ready, you may start a container and check everything is fine. The API requires Authentication to be running too, but API must run before Authentication. Below there is an example running a container and using a bind mount to provide the appsettings.json file:

docker container run --rm -it -v /deployments/sec/appsettings.api.json:/app/appsettings.json -p 8000:80 security/api

Running behind Reverse Proxies

Usually, in a reverse proxy environment, the published services will have path prefixes to have several services run under the same domain. To avoid any issues with URLs in Security API, it is recommended to fill the PATH_PREFIX environment variable in the container and disable any path prefix strip in the reverse proxy, Security API will do the rest.