CT1162: SEC-OUT-CRED-2: No fixed or forced null outbound credentials

CT1162.md

Introduction

Istio consists of several services that intercommunicate to form the service mesh control-plane. The Istio data-plane consists of a proxy mesh, where a proxy is deployed as a sidecar with each end-user application service. Mutual TLS (mTLS) can be used to secure end-user services running within or outside of the mesh and for securing Istio control-plane communication.

Problem Statement

Not allowing customers to define outbound credentials destroys the usefulness of authentication functionality on peers.

Informal Summary of Solution

When a product offering logs into other things on the network, it needs to use credentials the customer supplies, not require the customer to enable a particular credential or not let the customer have authentication at all. This applies to all credentials, including pass phrases and private keys.

Required Behavior

When you communicate using a protocol which supports outbound credentials--

1. Requirement: Let the administrator configure the outbound credential(s) to be used, except for unattended installation of a standalone device.

   Istio's Behavior: Istio's ServiceEntry resource enables adding additional entries into Istio’s internal service registry, so that Istio services can access/route to these manually specified services. These services can be external to the Istio mesh (e.g., web APIs) or mesh-internal services that are not part of the platform’s service registry (e.g., a set of VMs talking to services in Kubernetes). TLSSettings within the TrafficPolicy object of a DestinationRule can be used to configure outbound credentials for mTLS connections to external services. By default, mesh-internal services are unable to communicate with external services. An administrator must configure the outbound credential(s) to be used or call the external services directly.

2. Requirement: Let the administrator use a different credential for each peer, except in a broadcast or multicast protocol or when externally constrained.

   Istio's Behavior: Istio supports the use of seperate credentials (i.e. TLS cert/key pair) for communication to external services. This is accomplished by the TLSSettings object of Istio's DestinationRule resource. For example, the following rule configures a client to use mutual TLS for connections to upstream database cluster.

   kind: DestinationRule
   metadata:
     name: db-mtls
   spec:
     host: mydbserver.prod.svc.cluster.local
     trafficPolicy:
       tls:
         mode: MUTUAL
         clientCertificate: /etc/certs/myclientcert.pem
         privateKey: /etc/certs/client_private_key.pem
         caCertificates: /etc/certs/rootcacerts.pem
   

   The DestinationRule resource is combined with the ServiceEntry and VirtualService resources to allow different credentials for each external service.

3. Requirement: Support any outbound credential value that's legal for the protocol.

   Istio's Behavior: Istio provides two types of authentication:

   • Transport Authentication: Verifies the direct client making the connection. Istio offers mutual TLS as a full stack solution for transport authentication. You can easily turn on this feature without requiring service code changes.

   • Origin Authentication: Also known as end-user authentication, verifies the original client making the request as an end-user or device. Istio enables request-level authentication with JSON Web Token (JWT) validation and a streamlined developer experience for Auth0, Firebase Auth, Google Auth, and custom authentication schemes.

   The TLS protocol supports multiple forms of authentication, such as X.509 Certificates and Secure Remote Password (TLS-SRP). Istio does not support TLS-SRP and therefore does not meet this requirement.

4. Requirement: Don't supply any default outbound credential value, unless one of the following applies--

   • It's used only at initial installation, as with a device identity credential.
   • It's a modifiable value that's equivalent by convention to a null credential, for example "public" for an SNMP community string. This kind of default may encourage bad customer practices, and you SHOULD NOT do this unless there's a compelling reason to do so.
   • An external constraint requires a default.

   Istio's Behavior: By default, mesh-internal services are unable to communicate with external services. An administrator must configure the outbound credential(s) to be used or call the external services directly.