Auth
Authentication and authorization configs at gateways, security group level
Authentication
Field | Description | Validation Rule |
---|---|---|
jwt | tetrateio.api.tsb.auth.v2.Authentication.JWT oneof _authn | – |
rules | tetrateio.api.tsb.auth.v2.Authentication.Rules oneof _authn | – |
oidc | tetrateio.api.tsb.auth.v2.OIDCConfig | – |
JWT
Field | Description | Validation Rule |
---|---|---|
issuer | string Example: https://foobar.auth0.com Example: 1234567-compute@developer.gserviceaccount.com | string = { |
audiences | List of string The service name will be accepted if audiences is empty. | – |
jwksUri | string oneof _keys Optional if the key set document can either (a) be retrieved from OpenID Discovery of the issuer or (b) inferred from the email domain of the issuer (e.g. a Google service account). Example: Note: Only one of jwks_uri and jwks should be used. jwks_uri will be ignored if it does. | – |
jwks | string oneof _keys Note: Only one of jwks_uri and jwks should be used. jwks_uri will be ignored if it does. | – |
outputPayloadToHeader | string | – |
outputClaimToHeaders | List of tetrateio.api.tsb.auth.v2.Authentication.JWT.ClaimToHeader
[Experimental] This feature is a experimental feature. | – |
fromHeaders | List of tetrateio.api.tsb.auth.v2.Authentication.JWT.JWTHeader
List of header locations from which JWT is expected. For example, below is the location spec
if JWT is expected to be found in
Note: Multiple tokens present on the same request are not supported. The behaviour of authorization policies when there is more than one user identity is undefined | – |
ClaimToHeader
This message specifies the detail for copying claim to header.
Field | Description | Validation Rule |
---|---|---|
header | string | string = { |
claim | string | string = { |
JWTHeader
This message specifies a header location to extract JWT token.
Field | Description | Validation Rule |
---|---|---|
name | string | – |
prefix | string | – |
Rules
Field | Description | Validation Rule |
---|---|---|
jwt | List of tetrateio.api.tsb.auth.v2.Authentication.JWT Notice that an HTTP request without a JWT Token attached to it will NOT be rejected based on the rules defined here. Remember to define HTTP request authorization settings to achieve that. | – |
Authorization
Configuration for authorizing a HTTP request
Field | Description | Validation Rule |
---|---|---|
external | tetrateio.api.tsb.auth.v2.Authorization.ExternalAuthzBackend oneof _authz | – |
local | tetrateio.api.tsb.auth.v2.Authorization.LocalAuthz oneof _authz | – |
ExternalAuthzBackend
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
Field | Description | Validation Rule |
---|---|---|
uri | – | |
includeRequestHeaders | List of string | – |
tls | – |
LocalAuthz
Authorize the request in Envoy based on the JWT claims.
Field | Description | Validation Rule |
---|---|---|
rules | – |
ClientTLSSettings
Configure TLS parameters for the client
Field | Description | Validation Rule |
---|---|---|
mode | tetrateio.api.tsb.auth.v2.TLSMode | – |
files | tetrateio.api.tsb.auth.v2.TLSFileSource oneof _tls_key_source | – |
secretName | string oneof _tls_key_source | – |
subjectAltNames | List of string | – |
LocalAuthzRule
LocalAuthzRule
Bindings define the subjects that can access the resource a policy is attached to, and the conditions that need to be met for that access to be granted. A policy can have multiple bindings to configure different access controls for specific subjects.
Field | Description | Validation Rule |
---|---|---|
name | string | string = { |
from | List of tetrateio.api.tsb.auth.v2.Subject | – |
to | List of tetrateio.api.tsb.auth.v2.LocalAuthzRule.HttpOperation | – |
HttpOperation
Field | Description | Validation Rule |
---|---|---|
paths | List of string | repeated = { |
methods | List of string | repeated = { |
OIDCConfig
Configure OIDC authentication for a given hostname
Field | Description | Validation Rule |
---|---|---|
grantType | tetrateio.api.tsb.auth.v2.OIDCGrantType | enum = { |
clientId | string | string = { |
clientTokenSecret | string Kubernetes generic opaque secret should contain For exampleapiVersion: v1 metadata: name: bar namespace: foo data: istio_generic_secret: e2Jhc2U2NF9lbmNvZGVkX3Rva2VuX3NlY3JldH0= kind: Secret type: Opaque The secret must be present in the same namespace as the gateway or sidecar deployment for which the configuration is being applied for. The (gateway/ sidecar) deployment must also have RBAC permissions to view secrets in the current namespace. For gateways this is already configured, while for sidecar the permission should be added if not already present. The secret token stored will be URL encoded when sent to the OAuth server. | string = { |
redirectUri | string It can also be formulated from request parameters For example: %REQ(x-forwarded-proto)%://%REQ(:authority)%/callback This URI should not contain any query parameters. | string = { |
provider | tetrateio.api.tsb.auth.v2.OIDCProviderConfig | message = { |
authType | tetrateio.api.tsb.auth.v2.OIDCAuthType | enum = { |
authScopes | List of string | – |
redirectPathMatcher | string If not provided, default is derived from redirect_uri path Only exact match is configurable | – |
signoutPath | string If not provided, default is | – |
OIDCProviderConfig
OIDCProviderConfig defines the OIDC Provider configuration.
It has two modes dynamic
and static
meaning if the configuration
has to be derived from the Issuer's Well-Known endpoint dynamically
or is statically configured.
To use dynamic
configuration only issuer
field should be set. If any other
field along with issuer
is set then the configuration will be treated as static
.
For AUTHORIZATION_CODE grant type, fields that are needed if configuration is static
:
-
Issuer
-
AuthorizationEndpoint
-
TokenEndpoint
-
oneof (JwksURI or Jwks)
Field | Description | Validation Rule |
---|---|---|
issuer | string | string = { |
authorizationEndpoint | string | string = { |
tokenEndpoint | string | string = { |
jwksUri | string oneof _jwks_setting | string = { |
jwks | string oneof _jwks_setting | string = { |
Subject
Subject
A subject designates an actor (user, service, etc) that attempts to access a target resource. Subjects can be modeled with JWT tokens, service accounts, and decorated with attributes such as HTTP request headers, JWT token claims, etc. The fields that define a subject will be matched to incoming requests, to fully qualify where the request comes from, and to decide if the given request is allowed or not for the target resource. All the fields in a subject are evaluated as AND expressions.
Field | Description | Validation Rule |
---|---|---|
jwt | tetrateio.api.tsb.auth.v2.Subject.JWTClaims | – |
JWTClaims
JWT based subject
JWT based subjects qualify a subject by matching against a JWT token present in the request. By default the token is expected to be present in the 'Authorization' HTTP header, with the 'Bearer" prefix.
Field | Description | Validation Rule |
---|---|---|
iss | – | |
sub | – | |
other | map<string, string> | map = { |
TLSFileSource
TLSFileSource is used to load the keys and certificates from files accessible to the workload
Field | Description | Validation Rule |
---|---|---|
clientCertificate | string | – |
privateKey | string | – |
caCertificates | string | – |
OIDCAuthType
Configures how client_id and client_secret are sent in OAuth client to OAuth server requests.
Field | Number | Description |
---|---|---|
DEFAULT_AUTH_TYPE | 0 | If no authentication type is specified, the default authentication type will be used.
Currently, the default authentication type is set to |
URL_ENCODED_BODY | 1 | The |
BASIC_AUTH | 2 | The |
OIDCGrantType
Configures authentication flow to be used
Field | Number | Description |
---|---|---|
DEFAULT_GRANT_TYPE | 0 | If no grant type is explicitly specified, the default grant type will be used.
The specific behavior of the default grant type may vary based on the type of workload to which the authentication settings are applied.
Currently, only |
AUTHORIZATION_CODE | 1 | Use authorization code flow |
TLSMode
Describes how authentication is performed as part of establishing TLS connection
Field | Number | Description |
---|---|---|
DISABLED | 0 | TLS is not used and communication is in plaintext. |
SIMPLE | 1 | Only the server is authenticated. |
MUTUAL | 2 | Both the peers in the communication must present their certificate for TLS authentication |