OpenAPI Extensions
OpenAPI Extensions available to configure APIs.
OpenAPIExtension
Metadata describing an extension to the OpenAPI spec.
Field | Description | Validation Rule |
---|---|---|
name | string | – |
appliesTo | List of string | – |
required | bool | – |
OpenAPIExtensions
Available OpenAPI extensions to configure APi Gateway features in Service Bridge.
Field | Description | Validation Rule |
---|---|---|
x-tsb-service | string This service name will be used to generate all the routes for traffic coming to the associated paths. OpenAPI extension name: x-tsb-service<br/> Applies to: info, path<br/> Required: Required unless x-tsb-redirect or x-tsb-clusters is defined for the target paths. Example:
| – |
x-tsb-redirect | tetrateio.api.tsb.gateway.v2.Redirect OpenAPI extension name: x-tsb-redirect<br/> Applies to: path<br/> Required: false Example:
| – |
x-tsb-tls | tetrateio.api.tsb.gateway.v2.ServerTLSSettings OpenAPI extension name: x-tsb-redirect<br/> Applies to: server<br/> Required: false Example:
| – |
x-tsb-cors | tetrateio.api.tsb.gateway.v2.CorsPolicy OpenAPI extension name: x-tsb-cors<br/> Applies to: server<br/> Required: false Example:
| – |
x-tsb-authentication | tetrateio.api.tsb.auth.v2.Authentication OpenAPI extension name: x-tsb-authentication<br/> Applies to: server<br/> Required: Required if Authorization is based on JWT tokens. Example:
| – |
x-tsb-external-authorization | tetrateio.api.tsb.application.v2.OpenAPIExternalAuthzBackend OpenAPI extension name: x-tsb-external-authorization<br/> Applies to: server, path<br/> Required: false Example:
| – |
x-tsb-jwt-authorization | tetrateio.api.tsb.application.v2.OpenAPIExtensions.JWTAuthz Note that if this is configured, the This can be applied at the server or path level. When applied at the server level, the authorization rules will be enforced for all paths in that server. OpenAPI extension name: x-tsb-jwt-authorization<br/> Applies to: server, path<br/> Required: false Example:
| – |
x-tsb-ratelimiting | tetrateio.api.tsb.gateway.v2.RateLimitSettings This can be applied at the server, path and operation level.
Each rate limit setting is independent of the other.
Top level fields such as OpenAPI extension name: x-tsb-ratelimiting<br/> Applies to: server, path, operation<br/> Required: false Example:
| – |
x-tsb-external-ratelimiting | tetrateio.api.tsb.gateway.v2.ExternalRateLimitServiceSettings OpenAPI extension name: x-tsb-external-ratelimiting<br/> Applies to: server, path, operation<br/> Required: false Example:
| – |
x-tsb-wasm-extensions | tetrateio.api.tsb.application.v2.OpenAPIWasmExtensionAttachment OpenAPI extension name: x-tsb-wasm-extensions<br/> Applies to: info<br/> Required: false Example:
| – |
x-tsb-wasm-definitions | tetrateio.api.tsb.extension.v2.WasmExtension OpenAPI extension name: x-tsb-wasm-definitions<br/> Applies to: info<br/> Required: false Example:
| – |
x-tsb-waf | tetrateio.api.tsb.security.v2.WAFSettings OpenAPI extension name: x-tsb-waf<br/> Applies to: info<br/> Required: false Example:
| – |
x-tsb-clusters | tetrateio.api.tsb.gateway.v2.RouteToClusters This clusters name will be used to generate all the routes for traffic coming to the associated paths. OpenAPI extension name: x-tsb-clusters<br/> Applies to: info, path<br/> Required: Required unless x-tsb-redirect or x-tsb-service is defined for the target paths. Example:
| – |
x-tsb-transit | bool This setting plays a crucial role in traffic forwarding across two different clusters that may not have a direct connection to each other. It facilitates communication through the mesh network, creating an indirect link between them. Thus, even if a direct route does not exist, information exchange can still take place. If this extension is applied under the server of the 'info' section, it affects all paths listed in the 'spec' for that particular server. Consequently, these paths become exclusive to the mesh network, restricting their accessibility from outside the network. However, if this extension is applied to a single server listed in the path section, its impact is more specific. It only affects that particular path mentioned in the 'spec' for that server. In turn, this single path is made exclusive to the mesh network, shielding it from external access. This granular level of control can be beneficial in cases where only a specific path needs to be isolated, while others remain accessible. In both cases, this helps in controlling and managing traffic flow, especially in large distributed systems where security and traffic management are critical. This granular control allows for a flexible, security-focused approach to managing network traffic within the mesh network. OpenAPI extension name: x-tsb-transit<br/> Applies to: server<br/> Required: false Example:
| – |
JWTAuthz
Configures authorization rules based on the JWT token in an incoming request.
Field | Description | Validation Rule |
---|---|---|
claims | List of tetrateio.api.tsb.auth.v2.Subject.JWTClaims | – |
OpenAPIExternalAuthzBackend
Use an authorization server running at the specified URI. Support both HTTP and gRPC server.
It is recommended to enable TLS validation (SIMPLE or MUTUAL) to secure traffic
between workload and external authorization server
If you use gRPC, do not set includeRequestHeaders
OpenAPIExternalAuthzBackend extends the fields provided by ExternalAuthzBackend by adding the disabled field.
The x-tsb-external-authorization
annotation can be applied at:
-
The root level servers configuration
-
The path level servers configuration
-
Directly at the path level. In this case, only the
disabled
field can be set. If you want to change other fields from the external authorization, you must define a new alternative server for this path item with your desired external authorization configurations. An empty x-tsb-external-authorization block implies disabled: false
Field | Description | Validation Rule |
---|---|---|
uri | – | |
includeRequestHeaders | List of string | – |
tls | – | |
disabled | – |
OpenAPIWasmExtensionAttachment
OpenAPIWasmExtensionAttachment defines the WASM extension attached in an OpenAPI specification including the name to identify the extension and also the specific configuration that will override the global extension configuration.
Field | Description | Validation Rule |
---|---|---|
name | string | string = { |
config | google.protobuf.Struct | – |