Security Setting

trafficMode

tetrateio.api.tsb.security.v2.SecuritySetting.AuthenticationMode
Traffic authentication mode is used to specify if mTLS or plaintext traffic is accepted

–

http

tetrateio.api.tsb.auth.v2.Authentication
HTTP request authentication is used to configure authentication of origin/end-user credentials like JSON Web Token (JWT). It is highly recommended to set traffic authentication mode to REQUIRED so that it is transported only over mutual TLS

–

allow

List of tetrateio.api.tsb.security.v2.Rule
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.

–

denyAll

bool
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

List of tetrateio.api.tsb.security.v2.Rule
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.

–

mode

tetrateio.api.tsb.security.v2.AuthorizationSettings.Mode
A short cut for specifying the set of allowed callers.

–

serviceAccounts

List of string
When the mode is CUSTOM, serviceAccounts specify the allowed set of service accounts (and the workloads using them). Must be in the <namespace>/<service-account-name> 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 rules. Service account should be a valid kubernetes service account, which follows DNS Subdomain Names rules.

repeated = {
  items: {string:{pattern:^\\./\\*$|^[^.*]+/[*]{1}$|^[^.*]+/[^*]+$}}
}

http

tetrateio.api.tsb.auth.v2.Authorization
This is for configuring HTTP request authorization. Currently, we only support authorizing through an external backend/policy engine like OPA. Inline authorization rules for JWT are not yet supported for sidecars.

–

rules

tetrateio.api.tsb.security.v2.AuthorizationRules
When the mode is RULES, you can allow or deny workload-to-workload communication by specifying in the rules field which target workloads are allowed or denied to communicate with other target workloads. When the mode is RULES, if no authorization rules are provided all requests will be accepted.

–

from

tetrateio.api.tsb.security.v2.Rule.From
REQUIRED
From specifies the source of a request.

–

to

tetrateio.api.tsb.security.v2.Rule.To
REQUIRED
To specifies the destination of a request.

–

fqn

string
The target resource identified by FQN which will be the source of a request.

–

fqn

string
The target resource identified by FQN which will be the destination of a request.

–

authentication

tetrateio.api.tsb.security.v2.SecuritySetting.AuthenticationMode
DEPRECATED: Specifies whether the proxy workloads should accept only mutual TLS authenticated traffic or allow legacy plaintext traffic as well. This field is deprecated in favor of authentication_settings and will be removed in the future release

–

authorization

tetrateio.api.tsb.security.v2.AuthorizationSettings
The set of service accounts in one or more namespaces allowed or denied to access a workload (and hence its sidecar) in the mesh. Authorization is affected by the security setting’s defined propagation strategy. If STRICTER is used the most restrictive AuthorizationSettings mode along the configuration hierarchy will prevail.

AuthorizationSettings mode can only be changed from UNSET to DISABLED to CLUSTER to WORKSPACE to NAMESPACE to GROUP to RULES to CUSTOM. Restricting two CUSTOM AuthorizationSettings is a special case. A service account is considered stricter if it belongs to the same namespace and it has a concrete service account other than a wildcard. Hence, the only possibilities to restrict service accounts is from “ns/*” to “ns/svc1-sa”. When two lists of service accounts are compared (a parent and a child list) only the service accounts from the child list that are stricter (following the previously mentioned rules) or equal to any of the parent defined service accounts will be used. If none of the children’s service accounts is stricter or equal, then the parent defined list will be used. For instance, a parent defines “ns/*”, “ns2/svc-sa”, and “./*” service accounts, whereas a child defines “ns/svc1-sa”, “ns3/svc-sa”, and “./”. The effective strictest list will be “ns/svc1-sa”, and “./”. “ns3/svc2-sa” is discarded because it will extend the set of service accounts allowed to access the workload/s, as parent’s defined service accounts does not include “ns3/*” or “ns3/svc2-sa”.

Restricting two rules AuthorizationSettings is also a special case. To consider a rules stricter, both allowed and denied rules list need to be considered as stricter. Allowed rules can only be refined by subsets of the initial rule. Hence, you cannot allow more workloads, only less. For instance, if an allow rule from workspace w1 to w2 has been specified higher up in the hierarchy, it can only be refined with the same resource or lineage resources lower down in the resource hierarchy. Which means, if w1 has a child security group sg1, only sg1 and w1 itself are considered as a stricter from resource target. In the same way, if w2 has a child security group sg2, only sg2 and w2 itself are considered as a stricter to resource target. On the other hand, any provided list of denied rules lower down in the hierarchy, will be considered always stricter, because all ancestor’s denied rules are also taken into consideration. Basically, stricter rules AuthorizationSettings can only allow the same or less, and/or deny more workloads.

–

authenticationSettings

tetrateio.api.tsb.security.v2.AuthenticationSettings
Authentication settings is used to set workload-to-workload traffic and end-user/origin authentication configuration. Authentication settings is affected by the security setting’s defined propagation strategy. If STRICTER is used the most restrictive AuthenticationSettings traffic mode along the configuration hierarchy will prevail. AuthenticationSettings traffic mode can only be changed from UNSET to OPTIONAL to REQUIRED. Authentication settings http will use replace propagation strategy.

–

waf

tetrateio.api.tsb.security.v2.WAFSettings
NOTICE: this feature is in alpha stage and under active development. it would encounter breaking changes in further release and should not be adopted in production WAF settings is used to set firewall rules.

–

propagationStrategy

tetrateio.api.tsb.types.v2.PropagationStrategy
Propagation strategy specifies how a security setting is propagated along the configuration hierarchy. The default strategy is REPLACE. The propagation strategy from security settings can only be changed from REPLACE to STRICTER along the settings in the configuration hierarchy. Any security setting propagation strategy changed from the default one, higher up in the configuration hierarchy, will prevail over any other defined security setting propagation strategy further down in the configuration hierarchy. For instance, if an organization’s default security setting propagation strategy is changed to STRICTER, a restrictive propagation strategy will be used at tenant, workspace default security settings and group security settings. STRICTER propagation strategy will be used even though, tenant, workspace or group security settings specifies a REPLACE propagation strategy.

Security setting properties affected by the propagation strategy are:

• Authorization

• AuthenticationSettings

• Extension

All the other properties will use the default REPLACE propagation strategy. How each property affected by the propagation strategy will be restricted is explained in more detail at each property.

–

extension

List of tetrateio.api.tsb.types.v2.WasmExtensionAttachment
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.

–

configGenerationMetadata

tetrateio.api.tsb.types.v2.ConfigGenerationMetadata
Metadata values that will be add into the Istio generated configurations. When using YAML APIs liketctl or gitops, put them into the metadata.labels or metadata.annotations instead. This field is only necessary when using gRPC APIs directly.

–

UNSET

0

Inherit from parent if possible. Otherwise treated as DISABLED.

NAMESPACE

1

The workload allows traffic from any other authenticated workload in its own namespace.

GROUP

2

The workload allows traffic from any other authenticated workload in the security group.

WORKSPACE

3

The workload allows traffic from any other authenticated workload in the workspace.

CLUSTER

4

The workload allows traffic from any other authenticated workload in the cluster.

DISABLED

5

Authorization is disabled.

CUSTOM

6

The workload allows traffic from service accounts defined explicitly.

RULES

7

The workload allows or denies traffic from any other authenticated workload that belongs to the specified rules.

UNSET

0

Inherit from parent, if has one. Otherwise treated as OPTIONAL.

OPTIONAL

1

Accept both plaintext and mTLS authenticated connections.

REQUIRED

2

Accept only mutual TLS authenticated connections.