Skip to main content
logoTetrate Service BridgeVersion: 1.6.x

Workload Configuration

WorkloadConfiguration specifies configuration of the workload handling.

For example,

authentication:
jwt:
issuers:
- issuer: "https://mycompany.corp"
jwksUri: "https://mycompany.corp/jwks.json"
shortName: "mycorp"
tokenFields:
attributes:
jsonPath: .custom_attributes
deregistration:
propagationDelay: 15s

JwtAuthenticationConfiguration

JwtAuthenticationConfiguration specifies configuration of the workload authentication by means of an OIDC ID Token.

FieldDescriptionValidation Rule

issuers

List of tetrateio.api.onboarding.config.install.v1alpha1.JwtIssuer
List of permitted JWT issuers.

If a workload authenticates itself by means of an OIDC ID Token, the issuer of that token must be present in this list, otherwise authentication attempt will be declined.

repeated = {
  items: {message:{required:true}}
}

WorkloadAuthenticationConfiguration

WorkloadAuthenticationConfiguration specifies configuration of the workload authentication.

FieldDescriptionValidation Rule

jwt

tetrateio.api.onboarding.config.install.v1alpha1.JwtAuthenticationConfiguration
JWT authentication configuration.

WorkloadConfiguration

WorkloadConfiguration specifies configuration of the workload handling.

FieldDescriptionValidation Rule

authentication

tetrateio.api.onboarding.config.install.v1alpha1.WorkloadAuthenticationConfiguration
Workload authentication configuration.

deregistration

tetrateio.api.onboarding.config.install.v1alpha1.WorkloadDeregistrationConfiguration
Workload deregistration configuration.

WorkloadDeregistrationConfiguration

WorkloadDeregistrationConfiguration specifies configuration of the workload deregistration.

FieldDescriptionValidation Rule

propagationDelay

google.protobuf.Duration
Estimated amount of time it takes to propagate the unregistration event across all affected mesh nodes.

During this time interval affected proxies will continue making requests to the deregistered workload until the respective configuration update arrives.

To prevent traffic loss, Workload Onboarding Agent SHOULD delay shutdown of the the workload's sidecar for that time period.

As a rule of thumb, this value should remain relatively small, e.g. under 15 seconds. The reason for this is that shutdown flow on the workload's side is time-boxed. E.g., on VMs there is a stop timeout enforced by SystemD, while on AWS ECS there is a stop timeout enforced by ECS Agent. If you pick a delay value that is too big, Workload Onboarding Agent will delay shutdown of the sidecar for too long; as a result sidecar risks to get terminated abruptly instead of graceful connection draining.

Defaults to 10s.

duration = {
  required: true
  gte: {nanos:0}
}