Skip to main content
logoTetrate Service BridgeVersion: 1.5.x

Auth

Authentication and authorization configs at gateways, security group level

Authentication

FieldDescriptionValidation Rule

jwt

tetrateio.api.tsb.auth.v2.Authentication.JWT oneof _authn

JWT

FieldDescriptionValidation Rule

issuer

string
REQUIRED
Identifies the issuer that issued the JWT. See issuer A JWT with different iss claim will be rejected.

Example: https://foobar.auth0.com Example: 1234567-compute@developer.gserviceaccount.com

string = {
  min_len: 1
}

audiences

List of string
The list of JWT audiences. that are allowed to access. A JWT containing any of these audiences will be accepted.

The service name will be accepted if audiences is empty.

jwksUri

string oneof _keys
URL of the provider's public key set to validate signature of the JWT. See OpenID Discovery.

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: https://www.googleapis.com/oauth2/v1/certs

Note: Only one of jwks_uri and jwks should be used. jwks_uri will be ignored if it does.

jwks

string oneof _keys
JSON Web Key Set of public keys to validate signature of the JWT. See https://auth0.com/docs/jwks.

Note: Only one of jwks_uri and jwks should be used. jwks_uri will be ignored if it does.

Authorization

Configuration for authorizing a HTTP request

FieldDescriptionValidation 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

FieldDescriptionValidation Rule

uri

string

includeRequestHeaders

List of string

tls

tetrateio.api.tsb.auth.v2.ClientTLSSettings

LocalAuthz

Authorize the request in Envoy based on the JWT claims.

FieldDescriptionValidation Rule

rules

List of tetrateio.api.tsb.auth.v2.LocalAuthzRule

ClientTLSSettings

Configure TLS parameters for the client

FieldDescriptionValidation Rule

mode

tetrateio.api.tsb.auth.v2.TLSMode
Set this to DISABLED to disable TLS (not recommended from the security perspective), SIMPLE for one-way TLS and MUTUAL for mutual TLS (where client is required to present its certificate as well)

files

tetrateio.api.tsb.auth.v2.TLSFileSource oneof _tls_key_source
It is mandatory when mode is SIMPLE or MUTUAL

subjectAltNames

List of string
Subject alternative names is the list of names that are accepted as service name as part of TLS handshake

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.

FieldDescriptionValidation Rule

name

string
REQUIRED
A friendly name to identify the binding.

string = {
  min_len: 1
}

from

List of tetrateio.api.tsb.auth.v2.Subject
Subjects configure the actors (end users, other services) that are allowed to access the target resource.

to

List of tetrateio.api.tsb.auth.v2.LocalAuthzRule.HttpOperation
A set of HTTP rules that need to be satisfied by the HTTP requests to get access to the target resource.

HttpOperation

FieldDescriptionValidation Rule

paths

List of string
The request path where the request is made against. E.g. ["/accounts"].

repeated = {
  items: {string:{min_len:1}}
}

methods

List of string
The HTTP methods that are allowed by this rule. E.g. ["GET", "HEAD"].

repeated = {
  items: {string:{in:[GET,HEAD,POST,PUT,PATCH,DELETE,OPTIONS]}}
}

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.

FieldDescriptionValidation Rule

jwt

tetrateio.api.tsb.auth.v2.Subject.JWTClaims
JWT configuration to identity the subject.

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.

FieldDescriptionValidation Rule

iss

string

sub

string

other

map<string, string>
A set of arbitrary claims that are required to qualify the subject. E.g. "iss": "*@foo.com".

map = {
  keys: {string:{min_len:1}}
}

TLSFileSource

TLSFileSource is used to load the keys and certificates from files accessible to the workload

FieldDescriptionValidation Rule

clientCertificate

string
Certificate file to authenticate the client. This is mandatory for mutual TLS and must not be specified for simple (one-way) TLS

privateKey

string
Private key file associated with the client certificate. This is mandatory for mutual TLS and must not be specified for simple TLS

caCertificates

string
File containing CA certificates to verify the certificates presented by the server. This is mandatory for both simple and mutual TLS. Here are some common paths for the system CA bundle on Linux and can be specified here if the server certificate is signed by a well known authority, already part of the system CA bundle on the host - /etc/ssl/certs/ca-certificates.crt (Debian/Ubuntu/Gentoo etc.) /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem (CentOS/RHEL 7) /etc/pki/tls/certs/ca-bundle.crt (Fedora/RHEL 6)

TLSMode

Describes how authentication is performed as part of establishing TLS connection

FieldNumberDescription

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