Skip to main content
logoTetrate Service BridgeVersion: 1.8.x

Extend Security Rules

Tetrate enables you to create a well-defined, accurate and sustainable security policy that can grow smoothly with your Tetrate-managed estate.

The Platform Owner ("Platform") and Application Owners ("Apps") work together to create elements of your security policy:

  1. Identify Security blocks​

    The App Owner identifies flows that are required, but blocked by the current Tetrate security policy.

  2. Apply Security rules​

    The Platform Owner validates the required security exception, and implements it using Tetrate APIs.

  3. Audit Security rules​

    Periodically, the Platform Owner may wish to audit the current security policies to verify they are sufficient to meet security and compliance needs.

Platform: Before you begin​

This guide will cover access control configuration between workloads in a Zero-Trust environment. Workloads are authenticated by SPIFFE identifiers, issued and updated by the Istio-powered Tetrate platform. This guide does not cover the more advanced capabilities of JWT, OAuth or OIDC user authentication.

The guide begins with the recommended starting posture:

  • All workloads are issued with SPIFFE identifiers, and mTLS is required for all traffic. This means that external third-parties such as other services in the cluster or with access to the data path cannot read transactions, modify transactions or impersonate clients or services.
  • All communication is denied by default, with the exception that Workspaces are unlocked and internal traffic is permitted.
  • The default security propagationStrategy is REPLACE

What you need to know​

Tetrate Security Posture is configured using SecuritySetting stanzas. These stanzas appear in a hierarchy of resources:

  1. Organization-Wide OrganizationSetting/defaultSecuritySetting
  2. Per-Workspace WorkspaceSetting/defaultSecuritySetting. An Organization contains multiple Workspaces.
  3. Per-SecurityGroup SecuritySetting. SecurityGroups allow you to subdivide a Workspace into smaller sets of namespaces.
  4. Per-Service ServiceSecuritySetting. Within a Security Group, rules can be applied for individual services.

Within each resource, you can configure a SecuritySetting stanza.

PropagationStrategy​

  • When the SecuritySetting propagationStrategy is set to REPLACE, a lower-level resource can modify the Security Policy defined by a higher-level one.
  • When the SecuritySetting propagationStrategy is set to STRICTER, the Security Policy cannot be relaxed by a lower-level object configuration.

For more information, refer to the PropagationStrategy documentation.

Common Practices​

When configuring Security Policies, two common practices are:

  1. Top-Down, Open Workspaces

    First define high-level defaults:

    • denyAll at OrganizationSetting/defaultSecuritySetting, with propagationStrategy as REPLACE
    • mode: WORKSPACE at WorkspaceSetting/defaultSecuritySetting to allow inter-Workspace communications

    Fine-grained exceptions can then be added to allow certain flows. These exceptions are defined using per-SecurityGroup SecuritySetting and per-service ServiceSecuritySetting resources, and are written from the perspective of the target Security Group or Service.

    This approach is the easiest to manage, and provides App Owners with open workspaces in which to to deploy multi-service applications.

  2. Bottom-Up, Fine-grained Rules

    Define the initial posture:

    • Do not enable 'Deny-All' at the organizational level, but do set the propagationStrategy to be STRICTER.

    As soon as an Allow rule is defined at a lower level, requests that do not match that rule will be denied, and this will propagate up the hierarchy to deny all other requests by default. You can then maintain a list of explicit Allow rules, knowing that every thing else will be denied.

    This approach is harder to manage as you need to declare every Allow rule, but it provides stricter security.

Apps: Identify Security blocks​

When you wish to access a target service, you need to know the FQDN of that service. This is generally listed in the Tetrate service registry, but may also be present in other forms, such as a ServiceEntry. The service owner should be able to provide the FQDN.

When debugging access control problems, you can begin with a simple HTTP request from your client container to the target service:

kubectl exec deploy/ratings-v1 -n bookinfo -- curl -s productpage.bookinfo.svc.cluster.local:9080/productpage
# expect response 'RBAC: access denied' if the Tetrate policy denies access

If the client's curl command gets the text response RBAC: access denied, this indicates that the Tetrate platform configuration is blocking access. Other errors are caused by other (non-access control) reasons.

Defining Security Policies​

Security Policies are defined from the perspective of the target service; they define which clients are permitted to access the target. The owner of the target service should ask the Platform Owner to add an appropriate exception to the 'deny-access' security policy that is blocking access, so that the client can access the target service.

For both the client and target services, the Platform Owner will need to know:

  1. Service name
  2. Service serviceAccount (kubectl get pod -n bookinfo podname -o jsonpath="{.spec.serviceAccount}"))
  3. Namespace and Cluster for the service
  4. Tetrate Workspace

The Platform Owner will determine the appropriate security rule to open up the requested flow, based on their security practices. The security rule could be based on service-to-service, namespace-to-namespace, workspace-to-workspace or various combinations in between.

Platform: Apply Security rules​

Security Rules are configured from the perspective of the target service. They can be based on Security Groups in a Workspace, or individual Kubernetes Service Accounts. The Tetrate platform accumulates the rules, following the propagationStrategy at each level, and generates the complete security policy. This policy is implemented using Istio configuration within and between clusters.

When constructing rules, consider the following two questions:

What is the target?Where to place the rule
All-namespaces-in-a-WorkspaceUpdate the authorization stanza in WorkspaceSetting/defaultSecuritySetting.
Alternatively, you may wish to consider WorkspaceSetting/defaultSecuritySetting as immutable, and to make the change in a Workspace-wide Security Group instead
Some‑namespaces‑in‑a‑WorkspaceCreate an appropriate Security Group for the target, and update the authorization stanza in the SecuritySetting attached to that Security Group
A single, named serviceCreate a ServiceSecuritySetting for that service, attached to an appropriate Security Group in the Workspace. Update the authorization stanza in the ServiceSecuritySetting
What are the Sources?How to define the rule
The same namespaceSet AuthorizationSettings.mode to NAMESPACE
The same security groupSet AuthorizationSettings.mode to GROUP
The same WorkspaceSet AuthorizationSettings.mode to WORKSPACE
The same clusterSet AuthorizationSettings.mode to CLUSTER
Named Kubernetes ServiceAccountsSet AuthorizationSettings.mode to CUSTOM and list the ServiceAccounts
More fine-grained controlSet AuthorizationSettings.mode to RULES, and provide a list of allow and deny Workspaces and Security Groups

Begin with the SecuritySetting documentation (TSB / TSE) for a set of worked examples and more detailed documentation.

Use Istio primitives in DIRECT mode​

For advanced situations, it is also possible to define Security Policies directly, using Istio primitives. To do so:

  • Configure the Security Group to use configMode: DIRECT. This means that the Tetrate SecuritySettings APIs cannot be applied to this group
  • Create PeerAuthentication and AuthorizationPolicy Istio Security v1beta1 resources and attach these to the Security Group using annotations

The Tetrate Management Plane will reconcile these DIRECT mode configurations with other BRIDGED mode configuration, and generate appropriate data plane configuration.

Platform: Audit Security Rules​

Periodically, you may wish to audit the Security Rules implemented by Tetrate. You can use several Industry-standard tools to visualize the rules:

  • Kiali can inspect and visualize the generated Istio configuration
  • The Tetrate Platform can generate L3/4 Network Policies that are derived from the hierarchical Access Control Policies configured by the Platform Owner. These L3/4 Kubernetes Network Policies can then be inspected and visualized using a variety of third-party Kubernetes Network Policy visualization tools