​
Local and external service accounts

In Gateway, you can define two types of service accounts:
  1. Local: an identity created and managed by Conduktor Gateway, using the Gateway admin API with no external dependency. Gateway provides the means to generate a Service Account password with a configurable time-to-live. These credentials can then be shared with clients for authentication. This type of service account is useful when you don’t want to depend on an external identity provider. As Gateway manages the identity, this is only supported in the Gateway managed authentication mode. You may want to use local service accounts when sharing data with an external partner and you don’t want to manage a separate identity provider.
  2. External: an identity managed by an external system, such as by an OIDC identity provider or an mTLS certificate. Optionally, this identity can be given a more user-friendly name in Gateway. For instance, if Azure is used as the OIDC provider, the application principal recognized by Gateway defaults to a UUID generated by Azure. To enhance readability, this principal can be mapped to a Gateway external service account, letting you use a friendly name when declaring ACLs, Interceptors and audit logs within Gateway. Similar to Kafka’s SSL principal mapping rules .
Each service account is stored in an internal topic, _conduktor_${GATEWAY_CLUSTER_ID}_usermappings and includes a name (used when applying ACLs and interceptors) and an associated Virtual Cluster. By default, this is set to the default virtual cluster, passthrough. See the supported client authentication methods matrix for details.

​
Local service accounts

The local service accounts are useful if you want to manage the clients credentials directly within Conduktor Gateway. You can easily create, update, and delete them directly from Gateway’s Admin API. Find out how to manage a local service account using Gateway.

​
External service accounts

For external service accounts, the clients credentials are created and handled by a third-party identity provider (e.g. OIDC, mTLS). However, you might want to:
  • Refer to them using a friendly name in Gateway
  • Associate them to a Virtual Cluster
In these scenarios, you should create an external service account in Gateway, and link it to the principal given by your identity provider. This external service account will be the one used in Gateway to apply ACLs and Interceptors and will be logged in the Gateway Audit Log internal topic. Find out how to manage an external service accounts using Gateway.

​
Gateway service account groups

Application service accounts defined in Gateway that follow a common set of Interceptor rules can be grouped. This allows you to scope Interceptors for multiple service accounts.
These groups can’t be used for managing ACLs of the service accounts.

​
Create a service account group

Use the Gateway API to create a group. Find out more about this resource.

​
Apply an Interceptor to a group

Once a group is created, you can apply Interceptors to it directly from within the Interceptor configuration. Use metadata.scope.group to define which group the Interceptor should apply to. Find out more.