Version: 1.4.x

Security Setting

SecuritySetting allows configuring security related properties such as TLS authentication and access control for traffic arriving at a proxy workload in a security group.

The following example creates a security group for the proxy workloads in ns1, ns2 and ns3 namespaces owned by its parent workspace w1 under tenant mycompany and defines a security setting that only allows mutual TLS authenticated traffic from other proxy workloads in the same group.

apiVersion: security.tsb.tetrate.io/v2
kind: Group
metadata:
  name: t1
  workspace: w1
  tenant: mycompany
  organization: myorg
spec:
  namespaceSelector:
    names:
    - "*/ns1"
    - "*/ns2"
    - "*/ns3"
  configMode: BRIDGED

And the associated security settings for all proxy workloads in the group

apiVersion: security.tsb.tetrate.io/v2
kind: SecuritySetting
metadata:
  name: defaults
  group: t1
  workspace: w1
  tenant: mycompany
  organization: myorg
spec:
  authenticationSettings:
    trafficMode: REQUIRED
  authorization:
    mode: GROUP

The following example customizes the allowedSources to allow traffic from the namespaces within the group as well as the catalog-sa service account from ns4 namespace.

apiVersion: security.tsb.tetrate.io/v2
kind: SecuritySetting
metadata:
  name: custom
  group: t1
  workspace: w1
  tenant: mycompany
  organization: myorg
spec:
  authenticationSettings:
    trafficMode: REQUIRED
    http:
      jwt:
        issuer: "https://auth.tetrate.io"
        jwksUri: "https://oauth2.auth.tetrate.io/certs"
  authorization:
    mode: CUSTOM
    serviceAccounts:
    - "ns1/*"
    - "ns2/*"
    - "ns3/*"
    - "ns4/catalog-sa"
    http:
      external:
        uri: "https://policy.auth.tetrate.io"
        includeRequestHeaders:
        - authorization

The following example customizes the WafSettings to enforce embedded web application firewall rules on sidecars in namespaces reside in SecurityGroup. NOTICE: WafSettings is an experimental feature on alpha stage it ONLY support embedded core rule set (embedded_crs) in the ruleSets field. Please DO NOT use it in production.

apiVersion: security.tsb.tetrate.io/v2
kind: SecuritySetting
metadata:
  name: defaults
  group: t1
  workspace: w1
  tenant: mycompany
  organization: myorg
spec:
  wafSettings:
    ruleSets:
    - embedded_crs
    ruleEngineMode: ON

AuthenticationSettings

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.

Field	Description	Validation Rule
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	–

AuthorizationSettings

AuthorizationSettings define the set of service accounts in one or more namespaces allowed to access a workload (and hence its sidecar) in the mesh.

Field	Description	Validation Rule
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.	repeated = { items: `{string:{min_len: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.	–

Mode

A short cut for defining the common authorization patterns

Name	Number	Description
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.