Skip to main content

Know who changed your API gateway, what changed and when

A wrong change to a production gateway can take APIs down, and without a record nobody can say what happened. G8 checks each change against the role and the G8 engine, and records it before it’s applied.

Request a demoHow it works
The problem

Gateway changes that nobody can trace

Gateway configuration changes often. When it’s changed by hand, or by scripts with shared credentials, the trail is thin.

Changes typed again in Production

A change tested in Staging is retyped in Production, and small differences slip through.

With G8Copy a Route, Service or Upstream to another Environment and see what will change before you save.

Everyone can change everything

Shared administrator accounts make every change everyone’s.

With G8Roles per Environment decide who can view and who can change each kind of object.

No record of what happened

After an incident, nobody can say who changed what.

With G8Every change is recorded before it’s applied, with the values before and after. Refused attempts are recorded too.

How G8 handles it

Controlled changes from Staging to Production

Every gateway change made through G8 takes the same path: a role check, an audit record, the G8 engine’s check, then the change.

Environments

Promote a change after you see it

Copy a Route, Service or Upstream from Staging to Production. G8 shows what the copy will change there and which dependencies are missing, and nothing is written until you save.

  • Secrets are your choiceChoose whether secrets are copied with the object.
  • Protected EnvironmentsIn a protected Environment, deleting an object requires typing its name.
Access and roles

Decide who can change each Environment

Grant built-in or custom roles per Environment. A custom role sets what it can view and what it can manage. Automation uses service accounts whose tokens expire and can be revoked.

  • Directory groupsMap Microsoft Active Directory groups to roles.
Checked first

Checked by the G8 engine before it’s applied

The G8 engine checks each configuration change. If it refuses one, nothing is applied and its message appears under the field. If an object changed after you opened it, G8 stops your save and shows the conflict.

Audit

Recorded before it’s applied, refused attempts included

If the audit record can’t be written, the change isn’t applied. A record shows who acted, when, the Environment and the values before and after, with secrets masked. Attempts a role doesn’t allow are recorded with the permission they needed.

  • To your SIEMEvery audit record is also written as a structured log line your log collector can take to your SIEM.
  • Filter and exportFilter records and export them as CSV. You decide how long they’re kept.
Illustrative scenario

A platform team with Staging and Production

A typical setup, drawn to show how the parts fit together. It doesn’t describe a specific customer.

The situation

A platform team runs Staging and Production gateway clusters. Application teams ask for Route changes, and a deployment pipeline applies some of them.

Areas used
01Editors in Staging only

Application teams hold the Editor role in Staging and the Viewer role in Production.

02Promotion by the platform team

The platform team copies tested Routes to Production after looking at what the copy changes.

03The pipeline as a service account

The pipeline uses a service account token, so its changes are recorded under its own name.

See G8 in a demo

We’ll show your team a change copied from Staging to Production, a change a role wasn’t allowed to make and the audit record of both.

Request a demo