Security Context of TSB Components

In Kubernetes, a Security Context defines privilege and access control settings for a Pod or Container. It provides the ability to set many security-relevant parameters.

Tetrate Service Bridge (TSB) installation API provides the ability to configure security context for TSB components. The following sections describe how to configure security context for TSB components.

Operator Security Context

TSB uses operators to manage the lifecycle of TSB components. You can configure the security context for operators by setting the operator.deployment.podSecurityContext and operator.deployment.containerSecurityContext field in the TSB install custom resources or Helm values file. The following example can be used for the management plane, control plane, and data plane operator.

operator:
  deployment:
    podAnnotations:
      security-check: runtime/default
    podSecurityContext:
      fsGroup: 1000
      supplementalGroups:
      - 1000
    containerSecurityContext:
      runAsNonRoot: true
      readOnlyRootFilesystem: true
      runAsUser: 1000
      runAsGroup: 1000
      privileged: false
      allowPrivilegeEscalation: false

Components Security Context

To configure the security context for TSB management plane or control plane components, you have options to set defaultKubeSpec that will be used for all components, or set the security context in each component kubeSpec individually. The following example shows how to set the security context for all components and an individual component in the TSB install custom resources or Helm values file.

Note that in defaultKubeSpec, you can also set security context for TSB components that runs as Kubernetes job.

spec:
  components:
    # defaultKubeSpec will be used for all components
    defaultKubeSpec:
      deployment:
        pod_annotations:
          security-check: runtime/default
        podSecurityContext:
          fsGroup: 1000
          supplementalGroups:
          - 1000
        containerSecurityContext:
          runAsNonRoot: true
          readOnlyRootFilesystem: true
          runAsUser: 1000
          runAsGroup: 1000
          privileged: false
          allowPrivilegeEscalation: false
  oap:
    # security context for individual component
    kubeSpec:
      deployment:
        pod_annotations:
          security-check: runtime/default
        podSecurityContext:
          fsGroup: 2000
          supplementalGroups:
          - 2000
        containerSecurityContext:
          runAsNonRoot: true
          readOnlyRootFilesystem: true
          runAsUser: 2000
          runAsGroup: 2000
          privileged: false
          allowPrivilegeEscalation: false

Gateway Security Context

To configure TSB gateway security context, you can set kubeSpec.deployment.podSecurityContext or kubeSpec.deployment.containerSecurityContext field in TSB gateway installation custom resource.

apiVersion: install.tetrate.io/v1alpha1
kind: IngressGateway
metadata:
  name: bookinfo-gw
  namespace: bookinfo-gw
spec:
  kubeSpec:
    service:
      type: LoadBalancer
    deployment:
      pod_annotations:
        security-check: runtime/default
      podSecurityContext:
        fsGroup: 1000
        supplementalGroups:
        - 1000
      containerSecurityContext:
        runAsNonRoot: true
        readOnlyRootFilesystem: true
        runAsUser: 1000
        runAsGroup: 1000
        privileged: false
        allowPrivilegeEscalation: false

OpenShift Security Context

When deploying Tetrate Service Bridge (TSB) on OpenShift, especially from OpenShift Container Platform (OCP) version 4.12 and onwards, you should be aware of certain caveats. In these versions, OpenShift has enhanced the enforcement of User/Group and some other properties on a per-namespace basis.

If you, as a platform owner, try to update these properties, this could result in compatibility issues with the TSB due to these enhanced security enforcements. If the Security Context Constraints (SCCs) that come packaged with the TSB become incompatible with these updated properties, the TSB may become invalid.

Therefore, ensure that any changes to these properties align with the TSB requirements. If conflicts arise, it may necessitate updating the TSB or adjusting the SCC to permit the required permissions for the TSB.