Secure Deployment

The code has been written carefully. Authorisation is enforced per request, queries are parameterised, output is encoded, secrets are in a store, dependencies are current. The application is now deployed, and a set of decisions that have nothing to do with your source files decide how much of it is exposed.

There are two quantities to reduce. What is reachable: endpoints, ports, headers, error detail, anything that answers from outside. And what is present: every binary, tool, package and file sitting in the running environment, whether or not anything calls it. A compiler in a production container is not reachable from the internet, and it is still available to a process that ends up running there.

Most of this is configuration, and most of it is one-time work. That is the appeal of it — a small number of deliberate choices, made once per service, that hold until someone changes them. The rest of this lesson is those choices for the orders API running in a container.

var builder = WebApplication.CreateBuilder(args);

// Do not announce the server and its version. Small, free, permanent.
builder.WebHost.ConfigureKestrel(options => options.AddServerHeader = false);

// One consistent error shape for clients, with no internal detail in it.
builder.Services.AddProblemDetails();

builder.Services.AddHealthChecks();

var app = builder.Build();

if (app.Environment.IsDevelopment())
{
    // Development only. This page exists to tell you everything, which is
    // exactly why it must never answer a request in production.
    app.UseDeveloperExceptionPage();

    // The schema document, for local tooling. No execute-against-production UI.
    app.MapOpenApi();
}
else
{
    // The detail goes to the logs with a correlation id the caller can quote.
    app.UseExceptionHandler();
    app.UseStatusCodePages();
    app.UseHsts();
}

app.UseHttpsRedirection();

// Liveness only: a plain 200 or 503, with no dependency names in the body.
app.MapHealthChecks("/health/live");

app.MapControllers().RequireAuthorization();

app.Run();

• Every branch here depends on the environment being set correctly, which makes ASPNETCORE_ENVIRONMENT one of the more consequential settings in the deployment. A production container running with it set to Development has the exception page, and nothing else in this file matters. Assert the value at startup and log it once, so the mistake is visible.
• UseExceptionHandler with problem details gives every failure the same shape: a status code, a title, and no internals. An unhandled exception that reaches a caller can otherwise include a file path from the build machine, a table name, or a fragment of a connection string.
• The caller gets a correlation id and nothing else. That is not obstruction — it is the pairing from the logging lesson, where the detail is recorded in a place with tighter access and the id is what connects the two.
• AddServerHeader = false removes Kestrel's header. Check what your reverse proxy or platform adds as well, since the removal has to happen at whichever component answers last.
• Publishing the OpenAPI schema is a judgement call and depends on the API. What should not ship is a documentation UI that composes and sends requests to production, because it is a convenient console for anything that reaches it.
• There is no UseStaticFiles call, because this API serves no files. Add it only if it does, and never enable directory browsing — it is off by default, and it gets switched on while debugging a path problem and left on.
• The health endpoint returns liveness only. A detailed report naming each dependency, its host and its error text is a map of your internals available without authentication, and it is the most common accidental disclosure in an otherwise careful deployment. Keep the detailed check on an internal-only route or port.
• RequireAuthorization on the endpoints repeats the closed-by-default idea from the first lesson. Deployment hardening reduces what is exposed; it does not substitute for the endpoint refusing on its own.

securityContext:
  runAsNonRoot: true
  runAsUser: 10001              # matches the USER declared in the image
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

resources:
  limits:
    cpu: "1"
    memory: "512Mi"

env:
  - name: ASPNETCORE_ENVIRONMENT
    value: "Production"
  - name: ASPNETCORE_URLS
    value: "http://+:8080"      # above 1024, so binding needs no privilege

volumeMounts:
  - name: tmp
    mountPath: /tmp             # the one writable path the process needs

• runAsNonRoot is a guard rather than the fix. The image itself should declare a non-root USER; this setting makes the platform refuse to start an image that would run as root, so the mistake is caught at deploy time instead of running unnoticed for a year.
• The user id has to match what the image declares, and the application has to listen above port 1024, because binding a lower port needs privilege. That is why the URL is set to 8080 — a container listening on 80 is the usual reason a non-root attempt fails.
• allowPrivilegeEscalation: false and dropping all capabilities remove abilities the application never uses. The reasoning is narrow and worth stating: they do not stop a process being compromised, they reduce what it can do next.
• A read-only root filesystem means the process cannot modify its own image at run time. This one finds real issues on first attempt — temporary files, data protection keys, a cache directory — so expect to mount a writable volume for each genuine need, which is the point: each need becomes explicit.
• Resource limits are about availability rather than confidentiality. One container consuming a node's memory takes its neighbours with it, and an unbounded request can do that on purpose or by accident.
• ASPNETCORE_ENVIRONMENT is set explicitly, because every environment-gated branch in the previous section depends on it. Do not rely on a default, and do not rely on it having been set correctly on the image.
• Only non-secret values appear here. A deployment manifest is committed, templated, copied between environments and readable by anyone with access to the cluster, so secrets come from the store as the earlier lesson described.