Kernel R1 — Kong and Gateway Operations

1. Kong in the deployed request path

Client HTTPS → Nginx portal virtual host → Kong host route → authenticated HTTPS web/API gateway → module runtime → scoped database function.

Nginx terminates public TLS. Kong maps portal/API host and path to the web/API host. The authenticated host and IAM resolve the current session, domain/profile/roles, permitted menu/screen and control decisions. Axis provides rendering metadata. Successful Kong routing is not an authorization grant and must not bypass native module permissions.

This guide uses the 11 October portal closeout and its pre-change Kong projection plus deployment source. Current live version, plugins and routes have not been re-queried during document preparation. Configuration fields with no retained proof remain confirmation items.

T02 · T22.

2. Routes, service, TLS, policy and management

GW01 · Topology

GW02 · Recorded Kong version

GW03 · Public portal route

GW04 · API compatibility route

GW05 · Upstream

GW06 · Timeouts

GW07 · Admin API

GW08 · TLS and headers

GW09 · Forwarded request context

GW10 · Authentication ownership

GW11 · CORS / mutation origin

GW12 · Plugins

GW13 · Private service ports

GW14 · Observability

3. Read-only baseline collection

From an approved VM administrator session, use local Admin API GETs and whitelist only the required configuration fields. Commands below require jq and local Admin API access; adapt authentication to current management policy. These commands have not been run by this packaging task. Retain outputs in a protected operations record and add a sanitized projection to UAT evidence.

kong version
systemctl is-active nginx kong kernel-web.service
curl --fail --silent --show-error http://127.0.0.1:8001/services/kernel-mediflex | jq '{name,protocol,host,port,connect_timeout,read_timeout,write_timeout,retries,tls_verify}'
curl --fail --silent --show-error http://127.0.0.1:8001/routes/kernel-mediflex | jq '{name,hosts,paths,protocols,strip_path,preserve_host,service}'
curl --fail --silent --show-error http://127.0.0.1:8001/routes/kernel-portal | jq '{name,hosts,paths,protocols,strip_path,preserve_host,service}'
curl --fail --silent --show-error 'http://127.0.0.1:8001/plugins?size=1000' | jq '{plugins:[.data[]|{name,enabled,service,route,consumer}],next}'
sudo nginx -t

Follow any returned plugin pagination cursor and capture every page. Do not export plugin config, consumer credentials, private keys, session cookies or a raw service environment. Verify actual listen addresses/NSG rules and certificate expiry through authorized operations access. Do not assume the public proxy test proves the management port is private.

4. Verification scenarios and expected interpretation

5. Gateway incident triage and recovery

1. Check DNS/TLS and exact host first. If login fails before API routing, inspect Nginx certificate/virtual-host state and Kong proxy readiness.
2. For no matching route, compare host/path/protocol with the active Kong route; preserve_host and strip_path affect application routing and callback validation.
3. For upstream502/503/504, inspect kernel-web readiness, Kong upstream address and bounded service logs. Do not expose internal runtime ports as a workaround.
4. For401, verify session age and host-bound context. For403, verify selected profile/domain and native decision; do not weaken gateway authentication to fix IAM mappings.
5. For500 DB_EXEC_ERROR, capture correlation_id and use protected runtime/database diagnostics. A visible menu does not establish backend permission or database health.
6. After a failed edge change, follow the exact portal backup/rollback record. Test login, existing API route, callback binding and allow/deny behavior before resuming users.

Support escalation: edge/network → web gateway → IAM/Axis → module/DB owner according to the first failing layer. Retain UTC timestamps and sanitized evidence across layers.

Integrated Pre-UAT release

How to read the status: implementation delivery, engineering regression and client acceptance are separate milestones. The engineering results below describe work already tested. The editable client case results begin Awaiting client validation because this handover starts the client Pre-UAT phase.

Security testing and user-experience refinements continue during Pre-UAT. The final UAT decision will include closure or explicit acceptance of the relevant findings and the agreed review outcomes.

Delivered scope, current checks and client review plan · Feature register