Security

Breaking down a monolithic application into atomic services offers various benefits, including better agility, better scalabilityand better ability to reuse services.However, microservices also have particular security needs:

  • To defend against the man-in-the-middle attack, they need traffic encryption.

  • To provide flexible service access control, they need mutual TLS and fine-grained access policies.

  • To audit who did what at what time, they need auditing tools.

Istio Security tries to provide a comprehensive security solution to solve all these issues.

This page gives an overview on how you can use Istio security features to secure your services, wherever you run them.In particular, Istio security mitigates both insider and external threats against your data, endpoints, communication and platform.

Istio Security Overview

Istio Security Overview

The Istio security features provide strong identity, powerful policy, transparent TLS encryption, and authentication, authorizationand audit (AAA) tools to protect your services and data. The goals of Istio security are:

  • Security by default: no changes needed for application code and infrastructure

  • Defense in depth: integrate with existing security systems to provide multiple layers of defense

  • Zero-trust network: build security solutions on untrusted networks

Visit our Mutual TLS Migration docs to start using Istio security features with your deployed services.Visit our Security Tasks for detailed instructions to use the security features.

High-level architecture

Security in Istio involves multiple components:

  • Citadel for key and certificate management

  • Sidecar and perimeter proxies to implement secure communication and authorization between clients and servers

  • Pilot to distribute authentication policiesand secure naming information to the proxies

  • Mixer to manage auditing

Istio Security Architecture

Istio Security Architecture

In the following sections, we introduce the Istio security features in detail.

Istio identity

Identity is a fundamental concept of any security infrastructure. At the beginning of a service-to-service communication,the two parties must exchange credentials with their identity information for mutual authentication purposes.On the client side, the server’s identity is checked against the secure naminginformation to see if it is an authorized runner of the service.On the server side, the server can determine what information the client can access based on theauthorization policies,audit who accessed what at what time, charge clients based on the services they used,and reject any clients who failed to pay their bill from accessing the services.

In the Istio identity model, Istio uses the first-class service identity to determine the identity of a service.This gives great flexibility and granularity to represent a human user, an individual service, or a group of services.On platforms that do not have such identity available,Istio can use other identities that can group service instances, such as service names.

Istio service identities on different platforms:

  • Kubernetes: Kubernetes service account

  • GKE/GCE: may use GCP service account

  • GCP: GCP service account

  • AWS: AWS IAM user/role account

  • On-premises (non-Kubernetes): user account, custom service account, service name, Istio service account, or GCP service account.The custom service account refers to the existing service account just like the identities that the customer’s Identity Directory manages.

Istio security vs SPIFFE

The SPIFFE standard provides a specification for a framework capable of bootstrapping and issuing identities to servicesacross heterogeneous environments.

Istio and SPIFFE share the same identity document: SVID (SPIFFE Verifiable Identity Document).For example, in Kubernetes, the X.509 certificate has the URI field in the format ofspiffe://<domain>/ns/<namespace>/sa/<serviceaccount>.This enables Istio services to establish and accept connections with other SPIFFE-compliant systems.

Istio security and SPIRE, which is the implementation of SPIFFE, differ in the PKI implementation details.Istio provides a more comprehensive security solution, including authentication, authorization, and auditing.

PKI

The Istio PKI is built on top of Istio Citadel and securely provisions strong identities to every workload.Istio uses X.509 certificates to carry the identities in SPIFFE format.The PKI also automates the key & certificate rotation at scale.

Istio supports services running on both Kubernetes pods and on-premises machines.Currently we use different certificate key provisioning mechanisms for each scenario.

Kubernetes scenario

  • Citadel watches the Kubernetes apiserver, creates a SPIFFE certificate and key pair for each of the existing and new service accounts.Citadel stores the certificate and key pairs asKubernetes secrets.

  • When you create a pod, Kubernetes mounts the certificate and key pair to the pod according to its service account viaKubernetes secret volume.

  • Citadel watches the lifetime of each certificate, and automatically rotates the certificates by rewriting the Kubernetes secrets.

  • Pilot generates the secure naming information,which defines what service account or accounts can run a certain service.Pilot then passes the secure naming information to the sidecar Envoy.

On-premises machines scenario

  • Citadel creates a gRPC service to take Certificate Signing Requests (CSRs).

  • Node agent generates a private key and CSR, and sends the CSR with its credentials to Citadel for signing.

  • Citadel validates the credentials carried with the CSR, and signs the CSR to generate the certificate.

  • The node agent sends both the certificate received from Citadel and theprivate key to Envoy.

  • The above CSR process repeats periodically for certificate and key rotation.

Node agent in Kubernetes

Istio provides the option of using node agent in Kubernetes for certificate and key provisioning, as shown in the figure below.Note that the identity provisioning flow for on-premises machines will be similar in the near future, we only describe the Kubernetes scenario here.

PKI with node agents in Kubernetes

PKI with node agents in Kubernetes

The flow goes as follows:

  • Citadel creates a gRPC service to take CSR requests.

  • Envoy sends a certificate and key request via Envoy secret discovery service (SDS) API.

  • Upon receiving the SDS request, the node agent creates the private key and CSR before sending the CSR with its credentials to Citadel for signing.

  • Citadel validates the credentials carried in the CSR and signs the CSR to generate the certificate.

  • The node agent sends the certificate received from Citadel and the private key to Envoy via the Envoy SDS API.

  • The above CSR process repeats periodically for certificate and key rotation.

Use the node agent debug endpoint to view the secrets a node agent is actively serving to its client proxies. Navigate to /debug/sds/workload on the agent’s port 8080 to dump active workload secrets, or /debug/sds/gateway to dump active gateway secrets.

Authentication

Istio provides two types of authentication:

  • Transport authentication, also known as service-to-service authentication:verifies the direct client making the connection. Istio offers mutual TLSas a full stack solution for transport authentication. You caneasily turn on this feature without requiring service code changes. Thissolution:

    • Provides each service with a strong identity representing its role toenable interoperability across clusters and clouds.
    • Secures service-to-service communication and end-user-to-servicecommunication.
    • Provides a key management system to automate key and certificategeneration, distribution, and rotation.
  • Origin authentication, also known as end-user authentication: verifies theoriginal client making the request as an end-user or device.Istio enables request-level authentication with JSON Web Token (JWT) validationand a streamlined developer experience for open source OpenID Connect providerORY Hydra, Keycloak,Auth0,Firebase Auth,Google Auth, and custom auth.

In both cases, Istio stores the authentication policies in the Istio config store via a custom Kubernetes API.Pilot keeps them up-to-date for each proxy, along with the keys where appropriate.Additionally, Istio supports authentication in permissive mode to help you understand how a policy change can affect your security posturebefore it becomes effective.

Mutual TLS authentication

Istio tunnels service-to-service communication through the client side and server side Envoy proxies.For a client to call a server with mutual TLS authentication:

  • Istio re-routes the outbound traffic from a client to the client’s local sidecar Envoy.

  • The client side Envoy starts a mutual TLS handshake with the server side Envoy.During the handshake, the client side Envoy also does a secure naming check to verify thatthe service account presented in the server certificate is authorized to run the target service.

  • The client side Envoy and the server side Envoy establish a mutual TLS connection,and Istio forwards the traffic from the client side Envoy to the server side Envoy.

  • After authorization, the server side Envoy forwards the traffic to the server service through local TCP connections.

Permissive mode

Istio mutual TLS has a permissive mode, which allows a service to acceptboth plaintext traffic and mutual TLS traffic at the same time. Thisfeature greatly improves the mutual TLS onboarding experience.

Many non-Istio clients communicating with a non-Istio server presents aproblem for an operator who wants to migrate that server to Istio withmutual TLS enabled. Commonly, the operator cannot install an Istio sidecarfor all clients at the same time or does not even have the permissions todo so on some clients. Even after installing the Istio sidecar on theserver, the operator cannot enable mutual TLS without breaking existingcommunications.

With the permissive mode enabled, the server accepts both plaintext andmutual TLS traffic. The mode provides great flexibility for theon-boarding process. The server’s installed Istio sidecar takes mutual TLStraffic immediately without breaking existing plaintext traffic. As aresult, the operator can gradually install and configure the client’sIstio sidecars to send mutual TLS traffic. Once the configuration of theclients is complete, the operator can configure the server to mutual TLSonly mode. For more information, visit theMutual TLS Migration tutorial.

Secure naming

The secure naming information contains N-to-N mappings from the server identities, which are encoded in certificates,to the service names that are referred by discovery service or DNS.A mapping from identity A to service name B means “A is allowed and authorized to run service B”.Pilot watches the Kubernetes apiserver, generates the secure naming information, and distributes it securely to the sidecar Envoys.The following example explains why secure naming is critical in authentication.

Suppose the legitimate servers that run the service datastore only use the infra-team identity.A malicious user has certificate and key for the test-team identity.The malicious user intends to impersonate the service to inspect the data sent from the clients.The malicious user deploys a forged server with the certificate and key for the test-team identity.Suppose the malicious user successfully hijacked (through DNS spoofing, BGP/route hijacking, ARPspoofing, etc.) the traffic sent to the datastore and redirected it to the forged server.

When a client calls the datastore service, it extracts the test-team identity from the server’s certificate,and checks whether test-team is allowed to run datastore with the secure naming information.The client detects that test-team is not allowed to run the datastore service and the authentication fails.

Secure naming is able to protect against general network hijackings for HTTPS traffic. It can alsoprotect TCP traffic from general network hijackings except for DNS spoofing. It would fail to workfor TCP traffic if the attacker hijacks the DNS and modifies the IP address of the destination. Thisis because TCP traffic does not contain the hostname information and we can only rely on the IPaddress for routing. And this DNS hijack can happen even before the client-side Envoy receives thetraffic.

Authentication architecture

You can specify authentication requirements for services receiving requests inan Istio mesh using authentication policies. The mesh operator uses .yamlfiles to specify the policies. The policies are saved in the Istioconfiguration storage once deployed. Pilot, the Istio controller, watches theconfiguration storage. Upon any policy changes, Pilot translates the new policyto the appropriate configuration telling the Envoy sidecar proxy how to performthe required authentication mechanisms. Pilot may fetch the public key andattach it to the configuration for JWT validation. Alternatively, Pilotprovides the path to the keys and certificates the Istio system manages andinstalls them to the application pod for mutual TLS. You can find more info inthe PKI section.Istio sends configurations to the targeted endpoints asynchronously. Once theproxy receives the configuration, the new authentication requirement takeseffect immediately on that pod.

Client services, those that send requests, are responsible for followingthe necessary authentication mechanism. For origin authentication (JWT), theapplication is responsible for acquiring and attaching the JWT credential tothe request. For mutual TLS, Istio provides a destination rule.The operator can use the destination rule to instruct client proxies to makeinitial connections using TLS with the certificates expected on the serverside. You can find out more about how mutual TLS works in Istio inMutual TLS authentication.

Authentication Architecture

Authentication Architecture

Istio outputs identities with both types of authentication, as well as otherclaims in the credential if applicable, to the next layer:authorization. Additionally,operators can specify which identity, either from transport or originauthentication, should Istio use as ‘the principal’.

Authentication policies

This section provides more details about how Istio authentication policieswork. As you’ll remember from the Architecture section,authentication policies apply to requests that a service receives. Tospecify client-side authentication rules in mutual TLS, you need to specify theTLSSettings in the DestinationRule. You can find more information in ourTLS settings reference docs.Like other Istio configuration, you can specify authentication policies in.yaml files. You deploy policies using kubectl.

The following example authentication policy specifies that transportauthentication for the reviews service must use mutual TLS:

  1. apiVersion: "authentication.istio.io/v1alpha1"
  2. kind: "Policy"
  3. metadata:
  4.   name: "reviews"
  5. spec:
  6.   targets:
  7.   - name: reviews
  8.   peers:
  9.   - mtls: {}

Policy storage scope

Istio can store authentication policies in namespace-scope or mesh-scopestorage:

  • Mesh-scope policy is specified with a value of MeshPolicy for the kindfield and the name "default". For example:
  1. apiVersion: "authentication.istio.io/v1alpha1"
  2. kind: "MeshPolicy"
  3. metadata:
  4.   name: "default"
  5. spec:
  6.   peers:
  7.   - mtls: {}
  • Namespace-scope policy is specified with a value of "Policy" for the kindfield and a specified namespace. If unspecified, the default namespace isused. For example for namespace ns1:
  1. apiVersion: "authentication.istio.io/v1alpha1"
  2. kind: "Policy"
  3. metadata:
  4.   name: "default"
  5.   namespace: "ns1"
  6. spec:
  7.   peers:
  8.   - mtls: {}

Policies in the namespace-scope storage can only affect services in the samenamespace. Policies in mesh-scope can affect all services in the mesh. Toprevent conflict and misuse, only one policy can be defined in mesh-scopestorage. That policy must be named default and have an emptytargets: section. You can find more information on ourtarget selectors section.

Kubernetes currently implements the Istio configuration on Custom ResourceDefinitions (CRDs). These CRDs correspond to namespace-scope andcluster-scope CRDs and automatically inherit access protection via theKubernetes RBAC. You can read more on theKubernetes CRD documentation

Target selectors

An authentication policy’s targets specify the service or services to which thepolicy applies. The following example shows a targets: section specifyingthat the policy applies to:

  • The product-page service on any port.
  • The reviews service on port 9000.
  1. targets:
  2.  - name: product-page
  3.  - name: reviews
  4.    ports:
  5.    - number: 9000

If you don’t provide a targets: section, Istio matches the policy to allservices in the storage scope of the policy. Thus, the targets: section canhelp you specify the scope of the policies:

  • Mesh-wide policy: A policy defined in the mesh-scope storage with no targetselector section. There can be at most one mesh-wide policy in themesh.

  • Namespace-wide policy: A policy defined in the namespace-scope storage withname default and no target selector section. There can be at most onenamespace-wide policy per namespace.

  • Service-specific policy: a policy defined in the namespace-scope storage,with non-empty target selector section. A namespace can have zero, one, ormany service-specific policies.

For each service, Istio applies the narrowest matching policy. The order is:service-specific > namespace-wide > mesh-wide. If more than oneservice-specific policy matches a service, Istio selects one of them atrandom. Operators must avoid such conflicts when configuring their policies.

To enforce uniqueness for mesh-wide and namespace-wide policies, Istio acceptsonly one authentication policy per mesh and one authentication policy pernamespace. Istio also requires mesh-wide and namespace-wide policies to havethe specific name default.

If a service has no matching policies, both transport authentication andorigin authentication are disabled.

Transport authentication

The peers: section defines the authentication methods and associatedparameters supported for transport authentication in a policy. The section canlist more than one method and only one method must be satisfied for theauthentication to pass. However, as of the Istio 0.7 release, the onlytransport authentication method currently supported is mutual TLS.

The following example shows the peers: section enabling transportauthentication using mutual TLS.

  1. peers:
  2.   - mtls: {}

The mutual TLS setting has an optional mode parameter that defines thestrictness of the peer transport authentication. These modes are documentedin the Authentication Policy reference document.

The default mutual TLS mode is STRICT. Therefore, mode: STRICT is equivalent to all of the following:

  • - mtls: {}
  • - mtls:
  • - mtls: null

When you do not specify a mutual TLS mode, peers cannot use transportauthentication, and Istio rejects mutual TLS connections bound for the sidecar.At the application layer, services may still handle their own mutual TLS sessions.

Origin authentication

The origins: section defines authentication methods and associated parameterssupported for origin authentication. Istio only supports JWT originauthentication. You can specify allowed JWT issuers, and enable or disable JWT authentication for aspecific path. If all JWTs are disabled for a request path, authentication also passes as if there isnone defined.Similar to peer authentication, only one of the listed methods must besatisfied for the authentication to pass.

The following example policy specifies an origins: section for origin authentication that acceptsJWTs issued by Google. JWT authentication for path /health is disabled.

  1. origins:
  2. - jwt:
  3.     issuer: "https://accounts.google.com"
  4.     jwksUri: "https://www.googleapis.com/oauth2/v3/certs"
  5.     trigger_rules:
  6.     - excluded_paths:
  7.       - exact: /health

Principal binding

The principal binding key-value pair defines the principal authentication for apolicy. By default, Istio uses the authentication configured in the peers:section. If no authentication is configured in the peers: section, Istioleaves the authentication unset. Policy writers can overwrite this behaviorwith the USE_ORIGIN value. This value configures Istio to use the origin’sauthentication as the principal authentication instead. In future, we willsupport conditional binding, for example: USE_PEER when peer is X, otherwiseUSE_ORIGIN.

The following example shows the principalBinding key with a value ofUSE_ORIGIN:

  1. principalBinding: USE_ORIGIN

Updating authentication policies

You can change an authentication policy at any time and Istio pushes the changeto the endpoints almost in real time. However, Istio cannot guarantee that allendpoints receive a new policy at the same time. The following arerecommendations to avoid disruption when updating your authentication policies:

  • To enable or disable mutual TLS: Use a temporary policy with a mode: keyand a PERMISSIVE value. This configures receiving services to accept bothtypes of traffic: plaintext and TLS. Thus, no request is dropped. Once allclients switch to the expected protocol, with or without mutual TLS, you canreplace the PERMISSIVE policy with the final policy. For more information,visit the Mutual TLS Migration tutorial.
  1. peers:
  2. - mtls:
  3.     mode: PERMISSIVE
  • For JWT authentication migration: requests should contain new JWT beforechanging policy. Once the server side has completely switched to the newpolicy, the old JWT, if there is any, can be removed. Client applicationsneed to be changed for these changes to work.

Authorization

Istio’s authorization feature provides mesh-level, namespace-level, and workload-levelaccess control on workloads in an Istio Mesh. It provides:

  • Workload-to-workload and end-user-to-workload authorization.
  • A Simple API, it includes a single AuthorizationPolicy CRD, which is easy to use and maintain.
  • Flexible semantics, operators can define custom conditions on Istio attributes.
  • High performance, as Istio authorization is enforced natively on Envoy.
  • High compatibility, supports HTTP, HTTPS and HTTP2 natively, as well as any plain TCP protocols.

Authorization architecture

Istio Authorization

Istio Authorization Architecture

The above diagram shows the basic Istio authorization architecture. Operatorsspecify Istio authorization policies using .yaml files.

Each Envoy proxy runs an authorization engine that authorizes requests atruntime. When a request comes to the proxy, the authorization engine evaluatesthe request context against the current authorization policies, and returns theauthorization result, ALLOW or DENY.

Implicit enablement

There is no need to explicitly enable Istio’s authorization feature, you just applythe AuthorizationPolicy on workloads to enforce access control.

If no AuthorizationPolicy applies to a workload, no access control will be enforced,In other words, all requests will be allowed.

If any AuthorizationPolicy applies to a workload, access to that workload isdenied by default, unless explicitly allowed by a rule declared in the policy.

Currently AuthorizationPolicy only supports ALLOW action. This means that ifmultiple authorization policies apply to the same workload, the effect is additive.

Authorization policy

To configure an Istio authorization policy, you create anAuthorizationPolicy resource.

An authorization policy includes a selector and a list of rules. The selectorspecifies the target that the policy applies to, while the rules specify whois allowed to do what under which conditions. Specifically:

  • target refers to the selector section in the AuthorizationPolicy.
  • who refers to the from section in the rule of the AuthorizationPolicy.
  • what refers to the to section in the rule of the AuthorizationPolicy.
  • conditions refers to the when section in the rule of the AuthorizationPolicy.

Each rule has the following standard fields:

  • from: A list of sources.
  • to: A list of operations.
  • when: A list of custom conditions.

The following example shows an AuthorizationPolicy that allows two sources(service account cluster.local/ns/default/sa/sleep and namespace dev) to access theworkloads with labels app: httpbin and version: v1 in namespace foo when the requestis sent with a valid JWT token.

  1. apiVersion: security.istio.io/v1beta1
  2. kind: AuthorizationPolicy
  3. metadata:
  4.  name: httpbin
  5.  namespace: foo
  6. spec:
  7.  selector:
  8.    matchLabels:
  9.      app: httpbin
  10.      version: v1
  11.  rules:
  12.  - from:
  13.    - source:
  14.        principals: ["cluster.local/ns/default/sa/sleep"]
  15.    - source:
  16.        namespaces: ["dev"]
  17.    to:
  18.    - operation:
  19.        methods: ["GET"]
  20.    when:
  21.    - key: request.auth.claims[iss]
  22.      values: ["https://accounts.google.com"]

Policy Target

Policy scope (target) is determined by metadata/namespace and an optional selector.

The metadata/namespace tells which namespace the policy applies to. If set to theroot namespace, the policy applies to all namespaces in a mesh. The value ofroot namespace is configurable, and the default is istio-system. If set to anormal namespace, the policy will only apply to the specified namespace.

A workload selector can be used to further restrict where a policy applies.The selector uses pod labels to select the target workload. The workloadselector contains a list of {key: value} pairs, where the key is the name of the label.If not set, the authorization policy will be applied to all workloads in the same namespaceas the authorization policy.

The following example policy allow-read allows "GET" and "HEAD" access tothe workload with label app: products in the default namespace.

  1. apiVersion: security.istio.io/v1beta1
  2. kind: AuthorizationPolicy
  3. metadata:
  4.   name: allow-read
  5.   namespace: default
  6. spec:
  7.   selector:
  8.     matchLabels:
  9.       app: products
  10.   rules:
  11.   - to:
  12.     - operation:
  13.          methods: ["GET", "HEAD"]

Value matching

Exact match, prefix match, suffix match, and presence match are supported for mostof the field with a few exceptions (e.g., the key field under the when section,the ipBlocks under the source section and the ports field under the to section only support exact match).

  • Exact match. i.e., exact string match.
  • Prefix match. A string with an ending "". For example, "test.abc." matches "test.abc.com", "test.abc.com.cn", "test.abc.org", etc.
  • Suffix match. A string with a starting "". For example, ".abc.com" matches "eng.abc.com", "test.eng.abc.com", etc.
  • Presence match. is used to specify anything but not empty. You can specify a field must be present using the format fieldname: [""].This means that the field can match any value, but it cannot be empty. Note that it is different from leaving a field unspecified, which means anything including empty.

The following example policy allows access at paths with prefix "/test/" or suffix "/info".

  1. apiVersion: security.istio.io/v1beta1
  2. kind: AuthorizationPolicy
  3. metadata:
  4.   name: tester
  5.   namespace: default
  6. spec:
  7.   selector:
  8.     matchLabels:
  9.       app: products
  10.   rules:
  11.   - to:
  12.     - operation:
  13.         paths: ["/test/*", "*/info"]

Allow-all and deny-all

The example below shows a simple policy allow-all which allows full access to allworkloads in the default namespace.

  1. apiVersion: security.istio.io/v1beta1
  2. kind: AuthorizationPolicy
  3. metadata:
  4.   name: allow-all
  5.   namespace: default
  6. spec:
  7.   rules:
  8.   - {}

The example below shows a simple policy deny-all which denies access to all workloadsin the admin namespace.

  1. apiVersion: security.istio.io/v1beta1
  2. kind: AuthorizationPolicy
  3. metadata:
  4.   name: deny-all
  5.   namespace: admin
  6. spec:
  7.   {}

Custom conditions

You can also use the when section to specify additional conditions. For example, the followingAuthorizationPolicy definition includes a condition that request.headers[version] is either "v1" or "v2".In this case, the key is request.headers[version], which is an entry in the Istio attribute request.headers,which is a map.

  1. apiVersion: security.istio.io/v1beta1
  2. kind: AuthorizationPolicy
  3. metadata:
  4.  name: httpbin
  5.  namespace: foo
  6. spec:
  7.  selector:
  8.    matchLabels:
  9.      app: httpbin
  10.      version: v1
  11.  rules:
  12.  - from:
  13.    - source:
  14.        principals: ["cluster.local/ns/default/sa/sleep"]
  15.    to:
  16.    - operation:
  17.        methods: ["GET"]
  18.    when:
  19.    - key: request.headers[version]
  20.      values: ["v1", "v2"]

The supported key values of a condition are listed in theconditions page.

Authenticated and unauthenticated identity

If you want to make a workload publicly accessible, you need to leave thesource section empty. This allows sources from all (both authenticated andunauthenticated) users and workloads, for example:

  1. apiVersion: security.istio.io/v1beta1
  2. kind: AuthorizationPolicy
  3. metadata:
  4.  name: httpbin
  5.  namespace: foo
  6. spec:
  7.  selector:
  8.    matchLabels:
  9.      app: httpbin
  10.      version: v1
  11.  rules:
  12.  - to:
  13.    - operation:
  14.        methods: ["GET", "POST"]

To allow only authenticated users, set principal to "*" instead, for example:

  1. apiVersion: security.istio.io/v1beta1
  2. kind: AuthorizationPolicy
  3. metadata:
  4.  name: httpbin
  5.  namespace: foo
  6. spec:
  7.  selector:
  8.    matchLabels:
  9.      app: httpbin
  10.      version: v1
  11.  rules:
  12.  - from:
  13.    - source:
  14.        principals: ["*"]
  15.    to:
  16.    - operation:
  17.        methods: ["GET", "POST"]

Using Istio authorization on plain TCP protocols

Istio authorization supports workloads using any plain TCP protocols, such as MongoDB. In this case,you configure the authorization policy in the same way you did for the HTTP workloads.The difference is that certain fields and conditions are only applicable to HTTP workloads.These fields include:

  • The request_principals field in the source section of the authorization policy object
  • The hosts, methods and paths fields in the operation section of the authorization policy object

The supported conditions are listed in the conditions page.

If you use any HTTP only fields for a TCP workload, Istio will ignore HTTP only fields in theauthorization policy.

Assuming you have a MongoDB service on port 27017, the following example configures an authorizationpolicy to only allow the bookinfo-ratings-v2 service in the Istio mesh to access the MongoDB workload.

  1. apiVersion: "security.istio.io/v1beta1"
  2. kind: AuthorizationPolicy
  3. metadata:
  4.   name: mongodb-policy
  5.   namespace: default
  6. spec:
  7.  selector:
  8.    matchLabels:
  9.      app: mongodb
  10.  rules:
  11.  - from:
  12.    - source:
  13.        principals: ["cluster.local/ns/default/sa/bookinfo-ratings-v2"]
  14.    to:
  15.    - operation:
  16.        ports: ["27017"]

Using other authorization mechanisms

While we strongly recommend using the Istio authorization mechanisms,Istio is flexible enough to allow you to plug in your own authentication and authorization mechanisms via the Mixer component.To use and configure plugins in Mixer, visit our policies and telemetry adapters docs.

See also

Authorization Policy Trust Domain Migration

Shows how to migrate from one trust domain to another without changing authorization policy.

Authorization for HTTP traffic

Shows how to set up role-based access control for HTTP traffic.

Authorization for TCP traffic

Shows how to set up access control for TCP traffic.

Micro-Segmentation with Istio Authorization

Describe Istio's authorization feature and how to use it in various use cases.

Introducing the Istio v1beta1 Authorization Policy

Introduction, motivation and design principles for the Istio v1beta1 Authorization Policy.

App Identity and Access Adapter

Using Istio to secure multi-cloud Kubernetes applications with zero code changes.