Mixer Client

Describes the configuration state for the Mixer client library that’s built into Envoy.

IstioService

IstioService identifies a service and optionally service version. The FQDN of the service is composed from the name, namespace, and implementation-specific domain suffix (e.g. on Kubernetes, “reviews” + “default” + “svc.cluster.local” -> “reviews.default.svc.cluster.local”).

FieldTypeDescriptionRequired
namestring

The short name of the service such as “foo”.

No
namespacestring

Optional namespace of the service. Defaults to value of metadata namespace field.

No
domainstring

Domain suffix used to construct the service FQDN in implementations that support such specification.

No
servicestring

The service FQDN.

No
labelsmap<string, string>

Optional one or more labels that uniquely identify the service version.

Note: When used for a VirtualService destination, labels MUST be empty.

No

QuotaSpec

Determines the quotas used for individual requests.

FieldTypeDescriptionRequired
rulesQuotaRule[]

A list of Quota rules.

No

QuotaRule

Specifies a rule with list of matches and list of quotas. If any clause matched, the list of quotas will be used.

FieldTypeDescriptionRequired
matchAttributeMatch[]

If empty, match all request. If any of match is true, it is matched.

No
quotasQuota[]

The list of quotas to charge.

No

StringMatch

Describes how to match a given string in HTTP headers. Match is case-sensitive.

FieldTypeDescriptionRequired
exactstring (oneof)

exact string match

No
prefixstring (oneof)

prefix-based match

No
regexstring (oneof)

RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax).

No

AttributeMatch

Specifies a match clause to match Istio attributes

FieldTypeDescriptionRequired
clausemap<string, StringMatch>

Map of attribute names to StringMatch type. Each map element specifies one condition to match.

Example:

clause: source.uid: exact: SOURCEUID request.httpmethod: exact: POST

No

Quota

Specifies a quota to use with quota name and amount.

FieldTypeDescriptionRequired
quotastring

The quota name to charge

No
chargeint32

The quota amount to charge

No

QuotaSpecBinding

QuotaSpecBinding defines the binding between QuotaSpecs and one or more IstioService.

FieldTypeDescriptionRequired
servicesIstioService[]

One or more services to map the listed QuotaSpec onto.

Yes
quotaSpecsQuotaSpecReference[]

One or more QuotaSpec references that should be mapped to the specified service(s). The aggregate collection of match conditions defined in the QuotaSpecs should not overlap.

Yes

QuotaSpecBinding.QuotaSpecReference

QuotaSpecReference uniquely identifies the QuotaSpec used in the Binding.

FieldTypeDescriptionRequired
namestring

The short name of the QuotaSpec. This is the resource name defined by the metadata name field.

Yes
namespacestring

Optional namespace of the QuotaSpec. Defaults to the value of the metadata namespace field.

No

HTTPAPISpec

HTTPAPISpec defines the canonical configuration for generating API-related attributes from HTTP requests based on the method and uri templated path matches. It is sufficient for defining the API surface of a service for the purposes of API attribute generation. It is not intended to represent auth, quota, documentation, or other information commonly found in other API specifications, e.g. OpenAPI.

Existing standards that define operations (or methods) in terms of HTTP methods and paths can be normalized to this format for use in Istio. For example, a simple petstore API described by OpenAPIv2 here can be represented with the following HTTPAPISpec.

apiVersion: config.istio.io/v1alpha2
kind: HTTPAPISpec
metadata:
  name: petstore
  namespace: default
spec:
  attributes:
    attributes:
      api.service:
        stringValue: petstore.swagger.io
      api.version:
        stringValue: 1.0.0
  patterns:
  - attributes:
      attributes:
        api.operation:
          stringValue: findPets
    httpMethod: GET
    uriTemplate: /api/pets
  - attributes:
      attributes:
        api.operation:
          stringValue: addPet
    httpMethod: POST
    uriTemplate: /api/pets
  - attributes:
      attributes:
        api.operation:
          stringValue: findPetById
    httpMethod: GET
    uriTemplate: /api/pets/{id}
  - attributes:
      attributes:
        api.operation:
          stringValue: deletePet
    httpMethod: DELETE
    uriTemplate: /api/pets/{id}
  apiKeys:
  - query: api-key
FieldTypeDescriptionRequired
attributesAttributes

List of attributes that are generated when any of the HTTP patterns match. This list typically includes the “api.service” and “api.version” attributes.

No
patternsHTTPAPISpecPattern[]

List of HTTP patterns to match.

No
apiKeysAPIKey[]

List of APIKey that describes how to extract an API-KEY from an HTTP request. The first API-Key match found in the list is used, i.e. ‘OR’ semantics.

The following default policies are used to generate the request.api_key attribute if no explicit APIKey is defined.

`query: key, `query: api_key`, and then `header: x-api-key`
No

HTTPAPISpecPattern

HTTPAPISpecPattern defines a single pattern to match against incoming HTTP requests. The per-pattern list of attributes is generated if both the httpmethod and uritemplate match. In addition, the top-level list of attributes in the HTTPAPISpec is also generated.

pattern:
- attributes
    api.operation: doFooBar
  httpMethod: GET
  uriTemplate: /foo/bar
FieldTypeDescriptionRequired
attributesAttributes

List of attributes that are generated if the HTTP request matches the specified httpmethod and uritemplate. This typically includes the “api.operation” attribute.

No
httpMethodstring

HTTP request method to match against as defined by rfc7231. For example: GET, HEAD, POST, PUT, DELETE.

No
uriTemplatestring (oneof)

URI template to match against as defined by rfc6570. For example, the following are valid URI templates:

/pets
/pets/{id}
/dictionary/{term:1}/{term}
/search{?q*,lang}
No
regexstring (oneof)

RE2 style regex-based match (https://github.com/google/re2/wiki/Syntax)

No

APIKey

APIKey defines the explicit configuration for generating the request.api_key attribute from HTTP requests.

See API Keys for a general overview of API keys as defined by OpenAPI.

FieldTypeDescriptionRequired
querystring (oneof)

API Key is sent as a query parameter. query represents the query string parameter name.

For example, query=api_key should be used with the following request:

GET /something?api_key=abcdef12345
No
headerstring (oneof)

API key is sent in a request header. header represents the header name.

For example, header=X-API-KEY should be used with the following request:

GET /something HTTP/1.1
X-API-Key: abcdef12345
No

HTTPAPISpecReference

HTTPAPISpecReference defines a reference to an HTTPAPISpec. This is typically used for establishing bindings between an HTTPAPISpec and an IstioService. For example, the following defines an HTTPAPISpecReference for service foo in namespace bar.

- name: foo
  namespace: bar
FieldTypeDescriptionRequired
namestring

The short name of the HTTPAPISpec. This is the resource name defined by the metadata name field.

Yes
namespacestring

Optional namespace of the HTTPAPISpec. Defaults to the encompassing HTTPAPISpecBinding’s metadata namespace field.

No

HTTPAPISpecBinding

HTTPAPISpecBinding defines the binding between HTTPAPISpecs and one or more IstioService. For example, the following establishes a binding between the HTTPAPISpec petstore and service foo in namespace bar.

apiVersion: config.istio.io/v1alpha2
kind: HTTPAPISpecBinding
metadata:
  name: my-binding
  namespace: default
spec:
  services:
  - name: foo
    namespace: bar
  apiSpecs:
  - name: petstore
    namespace: default
FieldTypeDescriptionRequired
servicesIstioService[]

One or more services to map the listed HTTPAPISpec onto.

Yes
apiSpecsHTTPAPISpecReference[]

One or more HTTPAPISpec references that should be mapped to the specified service(s). The aggregate collection of match conditions defined in the HTTPAPISpecs should not overlap.

Yes

istio.mixer.v1.Attributes

Attributes represents a set of typed name/value pairs. Many of Mixer’s API either consume and/or return attributes.

Istio uses attributes to control the runtime behavior of services running in the service mesh. Attributes are named and typed pieces of metadata describing ingress and egress traffic and the environment this traffic occurs in. An Istio attribute carries a specific piece of information such as the error code of an API request, the latency of an API request, or the original IP address of a TCP connection. For example:

request.path: xyz/abc
request.size: 234
request.time: 12:34:56.789 04/17/2017
source.ip: 192.168.0.1
target.service: example

A given Istio deployment has a fixed vocabulary of attributes that it understands. The specific vocabulary is determined by the set of attribute producers being used in the deployment. The primary attribute producer in Istio is Envoy, although specialized Mixer adapters and services can also generate attributes.

The common baseline set of attributes available in most Istio deployments is defined here.

Attributes are strongly typed. The supported attribute types are defined by ValueType. Each type of value is encoded into one of the so-called transport types present in this message.

Defines a map of attributes in uncompressed format. Following places may use this message: 1) Configure Istio/Proxy with static per-proxy attributes, such as source.uid. 2) Service IDL definition to extract api attributes for active requests. 3) Forward attributes from client proxy to server proxy for HTTP requests.

FieldTypeDescriptionRequired
attributesmap<string, AttributeValue>

A map of attribute name to its value.

No

NetworkFailPolicy

Specifies the behavior when the client is unable to connect to Mixer.

FieldTypeDescriptionRequired
policyFailPolicy

Specifies the behavior when the client is unable to connect to Mixer.

No
maxRetryuint32

Max retries on transport error.

No
baseRetryWaitDuration

Base time to wait between retries. Will be adjusted by exponential backoff and jitter.

No
maxRetryWaitDuration

Max time to wait between retries.

No

ServiceConfig

Defines the per-service client configuration.

FieldTypeDescriptionRequired
disableCheckCallsbool

If true, do not call Mixer Check.

No
disableReportCallsbool

If true, do not call Mixer Report.

No
mixerAttributesAttributes

Send these attributes to Mixer in both Check and Report. This typically includes the “destination.service” attribute. In case of a per-route override, per-route attributes take precedence over the attributes supplied in the client configuration.

No
httpApiSpecHTTPAPISpec[]

HTTP API specifications to generate API attributes.

No
quotaSpecQuotaSpec[]

Quota specifications to generate quota requirements.

No
networkFailPolicyNetworkFailPolicy

Specifies the behavior when the client is unable to connect to Mixer. This is the service-level policy. It overrides [mesh-level policy][istio.mixer.v1.config.client.TransportConfig.networkfailpolicy].

No
forwardAttributesAttributes

Default attributes to forward to upstream. This typically includes the “source.ip” and “source.uid” attributes. In case of a per-route override, per-route attributes take precedence over the attributes supplied in the client configuration.

Forwarded attributes take precedence over the static Mixer attributes, except in cases where there is clear configuration to ignore forwarded attributes. Gateways, for instance, should never use forwarded attributes.

The full order of application is as follows: 1. static Mixer attributes from the filter config; 2. static Mixer attributes from the route config; 3. forwarded attributes from the source filter config (if any and not ignored); 4. forwarded attributes from the source route config (if any and not ignored); 5. derived attributes from the request metadata.

No

TransportConfig

Defines the transport config on how to call Mixer.

FieldTypeDescriptionRequired
disableCheckCachebool

The flag to disable check cache.

No
disableQuotaCachebool

The flag to disable quota cache.

No
disableReportBatchbool

The flag to disable report batch.

No
networkFailPolicyNetworkFailPolicy

Specifies the behavior when the client is unable to connect to Mixer. This is the mesh level policy. The default value for policy is FAIL_OPEN.

No
statsUpdateIntervalDuration

Specify refresh interval to write Mixer client statistics to Envoy share memory. If not specified, the interval is 10 seconds.

No
checkClusterstring

Name of the cluster that will forward check calls to a pool of mixer servers. Defaults to “mixer_server”. By using different names for checkCluster and reportCluster, it is possible to have one set of Mixer servers handle check calls, while another set of Mixer servers handle report calls.

NOTE: Any value other than the default “mixer_server” will require the Istio Grafana dashboards to be reconfigured to use the new name.

No
reportClusterstring

Name of the cluster that will forward report calls to a pool of mixer servers. Defaults to “mixer_server”. By using different names for checkCluster and reportCluster, it is possible to have one set of Mixer servers handle check calls, while another set of Mixer servers handle report calls.

NOTE: Any value other than the default “mixer_server” will require the Istio Grafana dashboards to be reconfigured to use the new name.

No
attributesForMixerProxyAttributes

Default attributes to forward to Mixer upstream. This typically includes the “source.ip” and “source.uid” attributes. These attributes are consumed by the proxy in front of mixer.

No
reportBatchMaxEntriesuint32

When disablereportbatch is false, this value specifies the maximum number of requests that are batched in report. If left unspecified, the default value of reportbatchmax_entries == 0 will use the hardcoded defaults of istio::mixerclient::ReportOptions.

No
reportBatchMaxTimeDuration

When disablereportbatch is false, this value specifies the maximum elapsed time a batched report will be sent after a user request is processed. If left unspecified, the default reportbatchmax_time == 0 will use the hardcoded defaults of istio::mixerclient::ReportOptions.

No

HttpClientConfig

Defines the client config for HTTP.

FieldTypeDescriptionRequired
transportTransportConfig

The transport config.

No
serviceConfigsmap<string, ServiceConfig>

Map of control configuration indexed by destination.service. This is used to support per-service configuration for cases where a mixerclient serves multiple services.

No
defaultDestinationServicestring

Default destination service name if none was specified in the client request.

No
mixerAttributesAttributes

Default attributes to send to Mixer in both Check and Report. This typically includes “destination.ip” and “destination.uid” attributes.

No
forwardAttributesAttributes

Default attributes to forward to upstream. This typically includes the “source.ip” and “source.uid” attributes.

No
ignoreForwardedAttributesbool

Whether or not to use attributes forwarded in the request headers to create the attribute bag to send to mixer. For intra-mesh traffic, this should be set to “false”. For ingress/egress gateways, this should be set to “true”.

No

TcpClientConfig

Defines the client config for TCP.

FieldTypeDescriptionRequired
transportTransportConfig

The transport config.

No
mixerAttributesAttributes

Default attributes to send to Mixer in both Check and Report. This typically includes “destination.ip” and “destination.uid” attributes.

No
disableCheckCallsbool

If set to true, disables Mixer check calls.

No
disableReportCallsbool

If set to true, disables Mixer check calls.

No
connectionQuotaSpecQuotaSpec

Quota specifications to generate quota requirements. It applies on the new TCP connections.

No
reportIntervalDuration

Specify report interval to send periodical reports for long TCP connections. If not specified, the interval is 10 seconds. This interval should not be less than 1 second, otherwise it will be reset to 1 second.

No

NetworkFailPolicy.FailPolicy

Describes the policy.

NameDescription
FAIL_OPEN

If network connection fails, request is allowed and delivered to the service.

FAIL_CLOSE

If network connection fails, request is rejected.

Was this information useful?
Do you have any suggestions for improvement?

Thanks for your feedback!