--- title: "Get the details for the given settings object." method: GET path: "/v2/organizations/{organization}/settings/{setting}" tags: ["Organizations"] --- # Get the details for the given settings object. `GET /v2/organizations/{organization}/settings/{setting}` ## Request - Base URL: `https://docs.tetrate.io` (the document declares no server; this is the origin it was published from) - URL: `https://docs.tetrate.io/v2/organizations/{organization}/settings/{setting}` - Auth: none declared - TypeScript: (a function with typed inputs; its response is checked against the schema) ## Path parameters - `organization` string, required - `setting` string, required ## Response `200` A successful response. - V2OrganizationSetting: Settings that apply globally to the entire organization. - `fqn` string - `displayName` string - `etag` string - `description` string - `networkSettings` OrganizationSettingNetworkSettings: Network related settings for clusters. - `networkReachability` object: Reachability between clusters on various networks. Each cluster has a "network" field representing a network boundary like a VPC on AWS/GCP/Azure. All clusters within the same network are assumed to be reachable to each other for multi-cluster routing. In addition, you can specify additional connectivity between various networks in the mesh here. For example on AWS, each VPC can be treated as a distinct network. VPCs that are reachable to one another (through peering or transit gateways) can be listed as reachable networks. The key is the network name and the value is a comma separated list of networks whose clusters are reachable from this network. For instance, vpc01: vpc02,vpc03 means that the clusters in the network can reach those in vpc02 and vpc03. Note that reachability is **not** bidirectional. That is, if `vpc01: vpc02` is specified, then `vpc01` can reach `vpc02`, but not the other way around. Hence, the workloads in clusters in `vpc01` can access the services through the exposed gateway hostnames in clusters in `vpc02` . However, the workloads in clusters in `vpc02` cannot access the services exposed through the gateway hostnames in `vpc01`. - `regionalFailover` V2RegionalFailover[]: Default locality routing settings for all gateways. Explicitly specify the region traffic will land on when endpoints in local region becomes unhealthy. Should be used together with OutlierDetection to detect unhealthy endpoints. Note: if no OutlierDetection specified, this will not take effect. - `from` string: Originating region. - `to` string: Destination region the traffic will fail over to when endpoints in the 'from' region become unhealthy. - `defaultSecuritySetting` V2SecuritySetting: A security setting applies configuration to a set of proxy workloads in a security group or a workspace. When applied to a security group, missing fields will inherit values from the workspace-wide setting if any. - `fqn` string - `displayName` string - `etag` string - `description` string - `authentication` 'UNSET' | 'OPTIONAL' | 'REQUIRED': AuthenticationMode indicates whether to accept only Istio mutual TLS authenticated traffic or allow legacy plaintext traffic as well. - UNSET: Inherit from parent, if has one. Otherwise treated as OPTIONAL. - OPTIONAL: Accept both plaintext and mTLS authenticated connections. - REQUIRED: Accept only mutual TLS authenticated connections. - `authorization` V2AuthorizationSettings: `AuthorizationSettings` define the set of service accounts in one or more namespaces allowed to access a workload (and hence its sidecar) in the mesh. - `mode` 'UNSET' | 'NAMESPACE' | 'GROUP' | 'WORKSPACE' | 'CLUSTER' | 'DISABLED' | 'CUSTOM' | 'RULES': - UNSET: Inherit from parent if possible. Otherwise treated as `DISABLED`. - NAMESPACE: The workload allows traffic from any other authenticated workload in its own namespace. - GROUP: The workload allows traffic from any other authenticated workload in the security group. - WORKSPACE: The workload allows traffic from any other authenticated workload in the workspace. - CLUSTER: The workload allows traffic from any other authenticated workload in the cluster. - DISABLED: Authorization is disabled. - CUSTOM: The workload allows traffic from service accounts defined explicitly. - RULES: The workload allows or denies traffic from any other authenticated workload that belongs to the specified rules. - `serviceAccounts` string[]: When the mode is `CUSTOM`, `serviceAccounts` specify the allowed set of service accounts (and the workloads using them). Must be in the `/` format. - `./*` indicates all service accounts in the namespace where the sidecar resides. - `ns1/*` indicates all service accounts in the `ns1` namespace. - `ns1/svc1-sa` indicates `svc1-sa` service account in `ns1` namespace. Namespace should be a valid kubernetes namespace, which follows [RFC 1123 Label Names](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-label-names) rules. Service account should be a valid kubernetes service account, which follows [DNS Subdomain Names](https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#dns-subdomain-names) rules. - `http` Tsbauthv2Authorization - `external` Tsbauthv2AuthorizationExternalAuthzBackend - `uri` string - `includeRequestHeaders` string[] - `tls` V2ClientTLSSettings - `mode` 'DISABLED' | 'SIMPLE' | 'MUTUAL': - DISABLED: TLS is not used and communication is in plaintext. - SIMPLE: Only the server is authenticated. - MUTUAL: Both the peers in the communication must present their certificate for TLS authentication - `files` V2TLSFileSource - … - `secretName` string: TLS key source from a Kubernetes Secret. This is applicable for gateway workloads. - `subjectAltNames` string[] - `local` Tsbauthv2AuthorizationLocalAuthz: Authorize the request in Envoy based on the JWT claims. - `rules` Tsbauthv2LocalAuthzRule[] - `name` string, required: A friendly name to identify the binding. - `from` Tsbauthv2Subject[]: Subjects configure the actors (end users, other services) that are allowed to access the target resource. - … - `to` Tsbauthv2LocalAuthzRuleHttpOperation[]: A set of HTTP rules that need to be satisfied by the HTTP requests to get access to the target resource. - … - `rules` V2AuthorizationRules: - If deny_all is true, deny the request - If deny is defined and there are any denied target workload, deny the request. - If there are no allowed target workload, allow the request. - If allow is defined and there are any allowed target workload, allow the request. - Deny the request. - `allow` V2Rule[]: Allow specifies a list of rules. If a request matches at least one rule, the request is accepted. If no allow rules are provided, all requests are allowed. Each rule must be unique, no duplicates are allowed. A rule that is fully contained by another rule is not allowed. For instance, defining a rule from workspace `w1` to `w2` and another rule from security group `sg1` (which belongs to workspace `w1`) to `sg2` (which belongs to workspace `w2`) is not allowed. It is not allowed, because from security group `sg1` to `sg2` rule is already allowed by the rule from workspace `w1` to `ws2`. - `from` RuleFrom, required: From includes the target resource (and the workloads that belong to the resource) which will be the source of a request. - `fqn` string: The target resource identified by FQN which will be the source of a request. - `to` RuleTo, required: To includes the target resource (and the workloads that belong to the resource) which will be destination of a request. - `fqn` string: The target resource identified by FQN which will be the destination of a request. - `denyAll` boolean: Deny all specifies whether all requests should be rejected. If it is true all requests will be rejected. If it is false the list of deny rules will be evaluated. - `deny` V2Rule[]: Deny specifies a list of rules. If a request matches at least one rule, the request is rejected. If deny rules are provided, the match will never occur, so no request can be rejected. Each rule must be unique, no duplicates are allowed. A rule that is fully contained by another rule is not allowed. For instance, defining a rule from workspace `w1` to `w2` and another rule from security group `sg1` (which belongs to workspace `w1`) to `sg2` (which belongs to workspace `w2`) is not allowed. It is not allowed, because from security group `sg1` to `sg2` rule is already denied by the rule from workspace `w1` to `w2`. - `from` RuleFrom, required: From includes the target resource (and the workloads that belong to the resource) which will be the source of a request. - `fqn` string: The target resource identified by FQN which will be the source of a request. - `to` RuleTo, required: To includes the target resource (and the workloads that belong to the resource) which will be destination of a request. - `fqn` string: The target resource identified by FQN which will be the destination of a request. - `authenticationSettings` V2AuthenticationSettings: AuthenticationSettings represents configuration related to authenticating traffic within the mesh and end-user credentials if present. It is **HIGHLY RECOMMENDED** to enable mutual TLS when end-user credentials are present. Sending credentials like JWT over plaintext is a security risk. - `trafficMode` 'UNSET' | 'OPTIONAL' | 'REQUIRED': AuthenticationMode indicates whether to accept only Istio mutual TLS authenticated traffic or allow legacy plaintext traffic as well. - UNSET: Inherit from parent, if has one. Otherwise treated as OPTIONAL. - OPTIONAL: Accept both plaintext and mTLS authenticated connections. - REQUIRED: Accept only mutual TLS authenticated connections. - `http` V2Authentication - `jwt` AuthenticationJWT - `issuer` string, required: Identifies the issuer that issued the JWT. See [issuer](https://tools.ietf.org/html/rfc7519#section-4.1.1) A JWT with different `iss` claim will be rejected. Example: https://foobar.auth0.com Example: 1234567-compute@developer.gserviceaccount.com - `audiences` string[]: The list of JWT [audiences](https://tools.ietf.org/html/rfc7519#section-4.1.3). 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: URL of the provider's public key set to validate signature of the JWT. See [OpenID Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata). Optional if the key set document can either (a) be retrieved from [OpenID Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html) 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: 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. - `outputPayloadToHeader` string: This field specifies the header name to output a successfully verified JWT payload to the backend. The forwarded data is `base64_encoded(jwt_payload_in_JSON)`. If it is not specified, the payload will not be emitted. - `outputClaimToHeaders` JWTClaimToHeader[]: This field specifies a list of operations to copy the claim to HTTP headers on a successfully verified token. This differs from the `output_payload_to_header` by allowing outputting individual claims instead of the whole payload. The header specified in each operation in the list must be unique. Nested claims of type string/int/bool is supported as well. ``` outputClaimToHeaders: - header: x-my-company-jwt-group claim: my-group - header: x-test-environment-flag claim: test-flag - header: x-jwt-claim-group claim: nested.key.group ``` [Experimental] This feature is a experimental feature. [TODO:Update the status whenever this feature is promoted.] - `header` string, required: The name of the header to be created. The header will be overridden if it already exists in the request. - `claim` string, required: The name of the claim to be copied from. Only claim of type string/int/bool is supported. The header will not be there if the claim does not exist or the type of the claim is not supported. - `fromHeaders` JWTJWTHeader[]: 1) The Authorization header using the Bearer schema, e.g. Authorization: Bearer . (see [Authorization Request Header Field](https://tools.ietf.org/html/rfc6750#section-2.1)) 2) The `access_token` query parameter (see [URI Query Parameter](https://tools.ietf.org/html/rfc6750#section-2.3)) List of header locations from which JWT is expected. For example, below is the location spec if JWT is expected to be found in `x-jwt-assertion` header, and have `Bearer ` prefix: ```yaml fromHeaders: - name: x-jwt-assertion prefix: "Bearer " ``` 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 - `name` string, required: The HTTP header name. - `prefix` string: The prefix that should be stripped before decoding the token. For example, for `Authorization: Bearer `, prefix=`Bearer ` with a space at the end. If the header doesn't have this exact prefix, it is considered invalid. - `rules` AuthenticationRules - `jwt` Tsbauthv2AuthenticationJWT[]: List of rules how to authenticate an HTTP request from a JWT Token attached to it. A JWT Token, if present in the HTTP request, must satisfy one of the rules defined here. The order in which rules are being checked at runtime might differ from the order in which they are defined here. If the JWT Token doesn't satisfy any of the rules, the request will be rejected. If the JWT Token does satisfy one of the rules, the identity of the request will be extracted from the JWT Token. 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. - `issuer` string, required: Identifies the issuer that issued the JWT. See [issuer](https://tools.ietf.org/html/rfc7519#section-4.1.1) A JWT with different `iss` claim will be rejected. Example: https://foobar.auth0.com Example: 1234567-compute@developer.gserviceaccount.com - `audiences` string[]: The list of JWT [audiences](https://tools.ietf.org/html/rfc7519#section-4.1.3). 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: URL of the provider's public key set to validate signature of the JWT. See [OpenID Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata). Optional if the key set document can either (a) be retrieved from [OpenID Discovery](https://openid.net/specs/openid-connect-discovery-1_0.html) 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: 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. - `outputPayloadToHeader` string: This field specifies the header name to output a successfully verified JWT payload to the backend. The forwarded data is `base64_encoded(jwt_payload_in_JSON)`. If it is not specified, the payload will not be emitted. - `outputClaimToHeaders` JWTClaimToHeader[]: This field specifies a list of operations to copy the claim to HTTP headers on a successfully verified token. This differs from the `output_payload_to_header` by allowing outputting individual claims instead of the whole payload. The header specified in each operation in the list must be unique. Nested claims of type string/int/bool is supported as well. ``` outputClaimToHeaders: - header: x-my-company-jwt-group claim: my-group - header: x-test-environment-flag claim: test-flag - header: x-jwt-claim-group claim: nested.key.group ``` [Experimental] This feature is a experimental feature. [TODO:Update the status whenever this feature is promoted.] - … - `fromHeaders` JWTJWTHeader[]: 1) The Authorization header using the Bearer schema, e.g. Authorization: Bearer . (see [Authorization Request Header Field](https://tools.ietf.org/html/rfc6750#section-2.1)) 2) The `access_token` query parameter (see [URI Query Parameter](https://tools.ietf.org/html/rfc6750#section-2.3)) List of header locations from which JWT is expected. For example, below is the location spec if JWT is expected to be found in `x-jwt-assertion` header, and have `Bearer ` prefix: ```yaml fromHeaders: - name: x-jwt-assertion prefix: "Bearer " ``` 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 - … - `waf` V2WAFSettings - `rules` string[], required: Rules to be leveraged by WAF. The parser evaluates the list of rules from the top to the bottom. - `propagationStrategy` 'REPLACE' | 'STRICTER': The PropagationStrategy is the key differentiating factor to decide how a security policy should be propagated and applied at runtime across clusters. The default propagation strategy is REPLACE, in which a lower level SecuritySetting in the configuration hierarchy replaces a higher level SecuritySetting. The STRICTER PropagationStrategy on the other hand makes sure the default SecuritySettings configured at the parent level are always enforced and propagated down the hierarchy unless additional SecuritySettings are defined and restricted further in the configuration hierarchy. * `REPLACE` should be used when resources in the hierarchy are allowed to override the default settings configured at the higher levels. * `STRICTER` should be used when the default settings must prevail, and the settings can only be made more restrictive by child resources at lower levels of the hierarchy. When a resource or property of it affected by the propagation strategy is propagated down the hierarchy, regardless of the defined strategy (`REPLACE` or `STRICTER`), a parent defined resource or a property of the resource will be used (propagated) in absence of a child resource or a property of it. For example, the following policy configures optional mTLS for traffic within the workspace, but it allows SecuritySettings to modify it. The example shows a workspace that configures service-to-service access so that only services in the same workspace can talk to each other. The `REPLACE` propagation policy allows individual settings to override it. In the example, the SecuritySettings allows services within that group to be reachable from any service in the cluster, regardless for the workspace they belong to, even though the Workspace restricts service-to-service access to only services in the Workspace. ```yaml apiVersion: api.tsb.tetrate.io/v2 kind: WorkspaceSetting metadata: name: w1-settings workspace: w1 tenant: mycompany organization: myorg spec: defaultSecuritySetting: propagationStrategy: REPLACE authorization: mode: WORKSPACE --- apiVersion: security.tsb.tetrate.io/v2 kind: SecuritySetting metadata: name: defaults group: t1 workspace: w1 tenant: mycompany organization: myorg spec: authorization: mode: CLUSTER ``` `STRICTER` propagation configures defaults that can be only be restricted down the hierarchy. The following example configures the same WorkspaceSetting but with a `STRICTER` propagation mode. The `defaults` SecuritySetting further narrows down that access to the `GROUP` scope, which is allowed because GROUP is more strict than WORKSPACE. However, the `defaults-invalid` SecuritySetting configures `CLUSTER` access, which would widen the scope defined at the Workspace. That settings will not be allowed based on the `STRICTER` propagation policy. ```yaml apiVersion: api.tsb.tetrate.io/v2 kind: WorkspaceSetting metadata: name: w1-settings workspace: w1 tenant: mycompany organization: myorg spec: defaultSecuritySetting: propagationStrategy: STRICTER authorization: mode: WORKSPACE --- apiVersion: security.tsb.tetrate.io/v2 kind: SecuritySetting metadata: name: defaults group: t1 workspace: w1 tenant: mycompany organization: myorg spec: authorization: mode: GROUP --- apiVersion: security.tsb.tetrate.io/v2 kind: SecuritySetting metadata: name: defaults-invalid group: t2 workspace: w1 tenant: mycompany organization: myorg spec: authorization: mode: CLUSTER ``` Further details of how security settings are resolved between in `STRICTER` mode between a parent and a child resource can be found in the [SecuritySettings reference](../../security/v2/security_setting#securitysetting). - REPLACE: Is the default configuration propagation strategy. A lower defined configuration in the hierarchy will replace a higher configuration in the hierarchy. Otherwise, if a lower configuration is not defined, the configuration higher up in the hierarchy will prevail. For instance, a defined default propagation strategy for workspace default security settings will replace tenant's defined default security settings. - STRICTER: STRICTER propagation strategy propagates the strictest configuration between a defined higher level and a defined lower level configuration in the hierarchy. If a lower level configuration in the hierarchy is not defined, the higher one will prevail. Which configuration is stricter than the other is defined by each concrete configuration that allows specifying a propagation strategy. - `extension` V2WasmExtensionAttachment[]: Extensions specifies all the WasmExtensions assigned to this SecuritySettings with the specific configuration for each extension. This custom configuration will override the one configured globally to the extension. Each extension has a global configuration including enabling and priority that will condition the execution of the assigned extensions. - `fqn` string, required: Fqn of the extension to be executed. - `config` object: Configuration parameters sent to the WASM plugin execution. This configuration will overwrite the one specified globally in the extension. This config will be passed as-is to the extension. It is up to the extension to deserialize the config and use it. - `match` V2TrafficSelector[]: Specifies the criteria to determine which traffic is passed to WasmExtension. If a traffic satisfies any of TrafficSelectors, the traffic passes to the WasmExtension. - `mode` 'UNDEFINED' | 'CLIENT' | 'SERVER' | 'CLIENT_AND_SERVER': WorkloadMode allows selection of the role of the underlying workload in network traffic. A workload is considered as acting as a SERVER if it is the destination of the traffic (that is, traffic direction, from the perspective of the workload is *inbound*). If the workload is the source of the network traffic, it is considered to be in CLIENT mode (traffic is *outbound* from the workload). - UNDEFINED: Default value, which will be interpreted by its own usage. - CLIENT: Selects for scenarios when the workload is the source of the network traffic. In addition, if the workload is a gateway, selects this. - SERVER: Selects for scenarios when the workload is the destination of the network traffic. - CLIENT_AND_SERVER: Selects for scenarios when the workload is either the source or destination of the network traffic. - `ports` V2PortSelector[]: Criteria for selecting traffic by their destination port. More specifically, for the outbound traffic, the destination port would be the port of the target service. On the other hand, for the inbound traffic, the destination port is the port bound by the server process in the same Pod. If one of the given `ports` is matched, this condition is evaluated to true. If not specified, this condition is evaluated to true for any port. - `number` integer, required - `configGenerationMetadata` V2ConfigGenerationMetadata: `ConfigGenerationMetadata` allows to setup extra metadata that will be added in the final Istio generated configurations. Like new labels or annotations. Defining the config generation metadata in tenancy resources (like organization, tenant, workspace or groups) works as default values for those configs that belong to it. Defining same config generation metadata in configuration resources (like ingress gateways, service routes, etc.) will replace the ones defined in the tenancy resources. - `labels` object: Set of key value paris that will be added into the `metadata.labels` field of the Istio generated configurations. - `annotations` object: Set of key value paris that will be added into the `metadata.annotations` field of the Istio generated configurations. - `defaultTrafficSetting` V2TrafficSetting: A traffic setting applies configuration to a set of proxy workloads in a traffic group or a workspace. When applied to a traffic group, missing fields will inherit values from the workspace-wide setting if any. - `fqn` string - `displayName` string - `etag` string - `description` string - `reachability` V2ReachabilitySettings: `ReachabilitySettings` define the set of services and hosts accessed by a workload (and hence its sidecar) in the mesh. Defining the set of services accessed by a workload (i.e. its dependencies) in advance reduces the memory and CPU consumption both the Istio control plane and the individual Envoy proxy workloads in the data plane. - `mode` 'UNSET' | 'NAMESPACE' | 'GROUP' | 'WORKSPACE' | 'CLUSTER' | 'CUSTOM': - UNSET: Inherit from parent if possible. Otherwise treated as `CLUSTER`. - NAMESPACE: The workload may talk to any service in its own namespace. - GROUP: The workload may talk to any service in the traffic group. - WORKSPACE: The workload may talk to any service in the workspace. - CLUSTER: The workload may talk to any service in the cluster. - CUSTOM: The workload may talk to services defined explicitly. - `hosts` string[]: When the mode is `CUSTOM`, `hosts` specify the set of services that the sidecar should be able to reach. Must be in the `/` format. - `./*` indicates all services in the namespace where the sidecar resides. - `ns1/*` indicates all services in the `ns1` namespace. - `ns1/svc1.com` indicates `svc1.com` service in `ns1` namespace. - `*/svc1.com` indicates `svc1.com` service in any namespace. - `resilience` V2ResilienceSettings: ResilienceSettings control the reliability knobs in Envoy when making outbound connections from a gateway or proxy workload. - `httpRequestTimeout` string: Timeout for HTTP requests. Disabled if not set. - `httpRetries` V2HTTPRetry: HTTPRetry defines the parameters for retrying API calls to a service. - `attempts` integer, required: Number of retries for a given request. The interval between retries will be determined automatically (25ms+). Actual number of retries attempted depends on the httpReqTimeout. - `perTryTimeout` string: Timeout per retry attempt for a given request. format: 1h/1m/1s/1ms. MUST BE >=1ms. - `retryOn` string: Specifies the conditions under which retry takes place. One or more policies can be specified using a ‘,’ delimited list. See the [retry policies](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/router_filter#x-envoy-retry-on) and [gRPC retry policies](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/router_filter#x-envoy-retry-grpc-on) for more details. - `tcpKeepalive` boolean: Deprecated. This field will be removed in upcoming releases. Please use the `keep_alive` field instead. If enabled, sets SO_KEEPALIVE on the socket to enable TCP keepalive. - `keepAlive` V2KeepAliveSettings: Keep Alive Settings. - `tcp` KeepAliveSettingsTcpKeepAliveSettings: TCP Keep Alive Settings. - `downstream` TcpKeepAliveSettingsTcpKeepAlive - `probes` integer: The total number of unacknowledged probes to send before deciding the connection is dead. Default is to use the OS level configuration, Linux defaults to 9. - `idleTime` integer: The number of seconds a connection needs to be idle before keep-alive probes start being sent. Default is to use the OS level configuration, Linux defaults to 7200s. - `interval` integer: The number of seconds between keep-alive probes. Default is to use the OS level configuration, Linux defaults to 75s. - `upstream` TcpKeepAliveSettingsTcpKeepAlive - `probes` integer: The total number of unacknowledged probes to send before deciding the connection is dead. Default is to use the OS level configuration, Linux defaults to 9. - `idleTime` integer: The number of seconds a connection needs to be idle before keep-alive probes start being sent. Default is to use the OS level configuration, Linux defaults to 7200s. - `interval` integer: The number of seconds between keep-alive probes. Default is to use the OS level configuration, Linux defaults to 75s. - `circuitBreakerSensitivity` 'UNSET' | 'LOW' | 'MEDIUM' | 'HIGH': Available sensitivity levels for the circuit breaker. - UNSET: Default values will be used. - LOW: Tolerate up to 20 consecutive 5xx or connection failures from an endpoint before ejecting it temporarily from the load balancing pool. - MEDIUM: Tolerate up to 10 consecutive 5xx or connection failures from an endpoint before ejecting it temporarily from the load balancing pool. - HIGH: Tolerate up to 5 consecutive 5xx or connection failures from an endpoint before ejecting it temporarily from the load balancing pool. - `egress` TrafficSettingEgressGateway: EgressGateway specifies the gateway where traffic external to the mesh will be redirected. - `host` string, required: Specifies the egress gateway hostname. Must be in `/` format. - `port` integer: Deprecated. This field is ignored and will be removed in upcoming releases. Specifies the port on the host to connect to. - `rateLimiting` V2RateLimiting: Configuration for ratelimiting HTTP/gRPC requests can be rate limited based on a variety of attributes in the request such as headers (including cookies), URL path/prefixes, client remote address etc. - `settings` V2RateLimitSettings: Configuration for ratelimiting HTTP/gRPC requests This has a list of rate limit rules that can be configured. With each rule a list of dimensions can be defined. A request counts towards the limit if all of the dimensions match the attributes of the request. When the matched requests exceed the limit, a 429 response is returned. - `rules` V2RateLimitSettingsRateLimitRule[], required: A list of rules for ratelimiting. Each rule defines a list of dimensions to match on and the rate limit value for the rule. Each rule is independant of the other. - `dimensions` V2RateLimitSettingsRateLimitDimension[], required: A list of dimensions to define each ratelimit rule. Requests count towards the ratelimit value only when each and every condition in a dimension is matched for a given HTTP request. - `remoteAddress` V2RateLimitSettingsRateLimitDimensionRemoteAddress: RateLimit based on the client's remote address, extracted from the trusted X-Forwarded-For header. - … - `header` RateLimitDimensionHeader - … - `limit` RateLimitSettingsRateLimitValue, required: RateLimitValue specifies the values that will be used to determine the rate limit. - `requestsPerUnit` integer, required: Specifies the value of the rate limit. - `unit` 'UNKNOWN' | 'SECOND' | 'MINUTE' | 'HOUR' | 'DAY', required: Units of time. - `failClosed` boolean: If the rate limit service is unavailable, the request will fail if failClosed is set to true. Defaults to false. - `timeout` string: The timeout in seconds for the rate limit server RPC. Defaults to 0.020 seconds (20ms). Traffic will not be allowed to the destination if failClosed is set to true and the request to the rate limit server times out. - `externalService` V2ExternalRateLimitServiceSettings: Configuration for ratelimiting using an external ratelimit server The ratelimit server must expose [Envoy's Rate Limit Service gRPC API](https://www.envoyproxy.io/docs/envoy/latest/configuration/other_features/rate_limit#config-rate-limit-service). If the rate limit service is called, and the response for any of the descriptors is over limit, a 429 response is returned. The rate limit filter also sets the x-envoy-ratelimited header. If there is an error in calling rate limit service or rate limit service returns an error and failure_mode_deny is set to true, a 500 response is returned. - `domain` string, required: The rate limit domain to use when calling the rate limit service. Ratelimit settings are namespaced to a domain. - `failClosed` boolean: If the rate limit service is unavailable, the request will fail if failClosed is set to true. Defaults to false. - `rateLimitServerUri` string, required: The URI at which the external rate limit server can be reached. - `rules` V2ExternalRateLimitServiceSettingsRateLimitRule[], required - `dimensions` V2ExternalRateLimitServiceSettingsRateLimitDimension[], required: A list of dimensions that are to be applied for this rate limit configuration. Order matters as the dimensions are processed sequentially and the descriptor is composed by appending descriptor entries in that sequence. If the condition for a dimension is not satisfied and cannot append a descriptor entry, no descriptor list is generated for the entire setting. - `sourceCluster` RateLimitDimensionSourceCluster: Emit descriptor entry - a key-value pair of the form `("source_cluster", "")` where `source_cluster` is the source envoy cluster (corresponding to the `--service-cluster` flag value set by Istio). - `destinationCluster` RateLimitDimensionDestinationCluster: Emit descriptor entry - a key-value pair of the form `("destination_cluster", "")` where `destination_cluster` is the destination envoy cluster to which traffic is bound to. - `remoteAddress` V2ExternalRateLimitServiceSettingsRateLimitDimensionRemoteAddress - `requestHeaders` RateLimitDimensionRequestHeaders: Emit descriptor entry - a key-value pair of the form `("", "")` where `descriptor_key` is a user specified key to emit when the HTTP header is seen. - … - `headerValueMatch` RateLimitDimensionHeaderValueMatch: Emit descriptor entry - a key-value pair of the form `("header_match", "")`, where `descriptor_value` is a user specified value corresponding to a header match event. - … - `timeout` string: The timeout in seconds for the external rate limit server RPC. Defaults to 0.020 seconds (20ms). Traffic will not be allowed to the destination if failClosed is set to true and the request to the rate limit server times out. - `tls` V2ClientTLSSettings - `mode` 'DISABLED' | 'SIMPLE' | 'MUTUAL': - DISABLED: TLS is not used and communication is in plaintext. - SIMPLE: Only the server is authenticated. - MUTUAL: Both the peers in the communication must present their certificate for TLS authentication - `files` V2TLSFileSource - `clientCertificate` string - `privateKey` string - `caCertificates` string - `secretName` string: TLS key source from a Kubernetes Secret. This is applicable for gateway workloads. - `subjectAltNames` string[] - `configGenerationMetadata` V2ConfigGenerationMetadata: `ConfigGenerationMetadata` allows to setup extra metadata that will be added in the final Istio generated configurations. Like new labels or annotations. Defining the config generation metadata in tenancy resources (like organization, tenant, workspace or groups) works as default values for those configs that belong to it. Defining same config generation metadata in configuration resources (like ingress gateways, service routes, etc.) will replace the ones defined in the tenancy resources. - `labels` object: Set of key value paris that will be added into the `metadata.labels` field of the Istio generated configurations. - `annotations` object: Set of key value paris that will be added into the `metadata.annotations` field of the Istio generated configurations. ## Other responses - `default`: An unexpected error response. --- [API](https://skmtc.dev/tetrate/apis/tetrate-service-bridge-api.md) - [All operations](https://skmtc.dev/tetrate/apis/tetrate-service-bridge-api/llms.txt) - [OpenAPI document](https://skmtc.dev/tetrate/apis/tetrate-service-bridge-api/revisions/2f19c3a1ae57?raw)