- Mixer Client
- APIKey
- AttributeMatch
- HTTPAPISpec
- HTTPAPISpecBinding
- HTTPAPISpecPattern
- HTTPAPISpecReference
- HttpClientConfig
- IstioService
- NetworkFailPolicy
- NetworkFailPolicy.FailPolicy
- Quota
- QuotaRule
- QuotaSpec
- QuotaSpecBinding
- QuotaSpecBinding.QuotaSpecReference
- ServiceConfig
- StringMatch
- TcpClientConfig
- TransportConfig
- istio.mixer.v1.Attributes
Mixer Client
Describes the configuration state for the Mixer client library that’s built into Envoy.
APIKey
APIKey defines the explicit configuration for generating therequest.api_key
attribute from HTTP requests.
See API Keysfor a general overview of API keys as defined by OpenAPI.
Field | Type | Description | Required |
---|---|---|---|
query | string (oneof) | API Key is sent as a query parameter. query represents thequery string parameter name.For example, query=api_key should be used with thefollowing request:
| Yes |
header | string (oneof) | API key is sent in a request header. header represents theheader name.For example, header=X-API-KEY should be used with thefollowing request:
| Yes |
cookie | string (oneof) | API key is sent in acookie,For example, cookie=X-API-KEY should be used for thefollowing request:
| Yes |
AttributeMatch
Specifies a match clause to match Istio attributes
Field | Type | Description | Required |
---|---|---|---|
clause | map<string, StringMatch> | Map of attribute names to StringMatch type.Each map element specifies one condition to match.Example:clause:source.uid:exact: SOURCE_UIDrequest.http_method:exact: POST | No |
HTTPAPISpec
HTTPAPISpec defines the canonical configuration for generatingAPI-related attributes from HTTP requests based on the method anduri templated path matches. It is sufficient for defining the APIsurface of a service for the purposes of API attributegeneration. It is not intended to represent auth, quota,documentation, or other information commonly found in other APIspecifications, e.g. OpenAPI.
Existing standards that define operations (or methods) in terms ofHTTP methods and paths can be normalized to this format for use inIstio. For example, a simple petstore API described by OpenAPIv2herecan 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
Field | Type | Description | Required |
---|---|---|---|
attributes | Attributes | List of attributes that are generated when any of the HTTPpatterns match. This list typically includes the “api.service”and “api.version” attributes. | No |
patterns | HTTPAPISpecPattern[] | List of HTTP patterns to match. | No |
apiKeys | APIKey[] | List of APIKey that describes how to extract an API-KEY from anHTTP request. The first API-Key match found in the list is used,i.e. ‘OR’ semantics.The following default policies are used to generate therequest.api_key attribute if no explicit APIKey is defined.
| No |
HTTPAPISpecBinding
HTTPAPISpecBinding defines the binding between HTTPAPISpecs and one or moreIstioService. For example, the following establishes a bindingbetween 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
Field | Type | Description | Required |
---|---|---|---|
services | IstioService[] | One or more services to map the listed HTTPAPISpec onto. | Yes |
apiSpecs | HTTPAPISpecReference[] | One or more HTTPAPISpec references that should be mapped tothe specified service(s). The aggregate collection of matchconditions defined in the HTTPAPISpecs should not overlap. | Yes |
HTTPAPISpecPattern
HTTPAPISpecPattern defines a single pattern to match againstincoming HTTP requests. The per-pattern list of attributes isgenerated if both the http_method and uri_template match. Inaddition, the top-level list of attributes in the HTTPAPISpec is alsogenerated.
pattern:
- attributes
api.operation: doFooBar
httpMethod: GET
uriTemplate: /foo/bar
Field | Type | Description | Required |
---|---|---|---|
attributes | Attributes | List of attributes that are generated if the HTTP request matchesthe specified http_method and uri_template. This typicallyincludes the “api.operation” attribute. | No |
httpMethod | string | HTTP request method to match against as defined byrfc7231. Forexample: GET, HEAD, POST, PUT, DELETE. | No |
uriTemplate | string (oneof) | URI template to match against as defined byrfc6570. For example, thefollowing are valid URI templates:
| Yes |
regex | string (oneof) | EXPERIMENTAL:ecmascript style regex-based match as defined byEDCA-262. Forexample,
| Yes |
HTTPAPISpecReference
HTTPAPISpecReference defines a reference to an HTTPAPISpec. This istypically used for establishing bindings between an HTTPAPISpec and anIstioService. For example, the following defines anHTTPAPISpecReference for service foo
in namespace bar
.
- name: foo
namespace: bar
Field | Type | Description | Required |
---|---|---|---|
name | string | The short name of the HTTPAPISpec. This is the resourcename defined by the metadata name field. | Yes |
namespace | string | Optional namespace of the HTTPAPISpec. Defaults to the encompassingHTTPAPISpecBinding’s metadata namespace field. | No |
HttpClientConfig
Defines the client config for HTTP.
Field | Type | Description | Required |
---|---|---|---|
transport | TransportConfig | The transport config. | No |
serviceConfigs | map<string, ServiceConfig> | Map of control configuration indexed by destination.service. Thisis used to support per-service configuration for cases where amixerclient serves multiple services. | No |
defaultDestinationService | string | Default destination service name if none was specified in theclient request. | No |
mixerAttributes | Attributes | Default attributes to send to Mixer in both Check andReport. This typically includes “destination.ip” and“destination.uid” attributes. | No |
forwardAttributes | Attributes | Default attributes to forward to upstream. This typicallyincludes the “source.ip” and “source.uid” attributes. | No |
ignoreForwardedAttributes | bool | Whether or not to use attributes forwarded in the request headers tocreate the attribute bag to send to mixer. For intra-mesh traffic,this should be set to “false”. For ingress/egress gateways, thisshould be set to “true”. | No |
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”).
Field | Type | Description | Required |
---|---|---|---|
name | string | The short name of the service such as “foo”. | No |
namespace | string | Optional namespace of the service. Defaults to value of metadata namespace field. | No |
domain | string | Domain suffix used to construct the service FQDN in implementations that support such specification. | No |
service | string | The service FQDN. | No |
labels | map<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 |
NetworkFailPolicy
Specifies the behavior when the client is unable to connect to Mixer.
Field | Type | Description | Required |
---|---|---|---|
policy | FailPolicy | Specifies the behavior when the client is unable to connect to Mixer. | No |
maxRetry | uint32 | Max retries on transport error. | No |
baseRetryWait | Duration | Base time to wait between retries. Will be adjusted by exponentialbackoff and jitter. | No |
maxRetryWait | Duration | Max time to wait between retries. | No |
NetworkFailPolicy.FailPolicy
Describes the policy.
Name | Description |
---|---|
FAIL_OPEN | If network connection fails, request is allowed and delivered to theservice. |
FAIL_CLOSE | If network connection fails, request is rejected. |
Quota
Specifies a quota to use with quota name and amount.
Field | Type | Description | Required |
---|---|---|---|
quota | string | The quota name to charge | No |
charge | int32 | The quota amount to charge | No |
QuotaRule
Specifies a rule with list of matches and list of quotas.If any clause matched, the list of quotas will be used.
Field | Type | Description | Required |
---|---|---|---|
match | AttributeMatch[] | If empty, match all request.If any of match is true, it is matched. | No |
quotas | Quota[] | The list of quotas to charge. | No |
QuotaSpec
Determines the quotas used for individual requests.
Field | Type | Description | Required |
---|---|---|---|
rules | QuotaRule[] | A list of Quota rules. | No |
QuotaSpecBinding
QuotaSpecBinding defines the binding between QuotaSpecs and one or moreIstioService.
Field | Type | Description | Required |
---|---|---|---|
services | IstioService[] | One or more services to map the listed QuotaSpec onto. | Yes |
quotaSpecs | QuotaSpecReference[] | One or more QuotaSpec references that should be mapped tothe specified service(s). The aggregate collection of matchconditions defined in the QuotaSpecs should not overlap. | Yes |
QuotaSpecBinding.QuotaSpecReference
QuotaSpecReference uniquely identifies the QuotaSpec used in theBinding.
Field | Type | Description | Required |
---|---|---|---|
name | string | The short name of the QuotaSpec. This is the resourcename defined by the metadata name field. | Yes |
namespace | string | Optional namespace of the QuotaSpec. Defaults to the value of themetadata namespace field. | No |
ServiceConfig
Defines the per-service client configuration.
Field | Type | Description | Required |
---|---|---|---|
disableCheckCalls | bool | If true, do not call Mixer Check. | No |
disableReportCalls | bool | If true, do not call Mixer Report. | No |
mixerAttributes | Attributes | Send these attributes to Mixer in both Check and Report. Thistypically includes the “destination.service” attribute.In case of a per-route override, per-route attributes take precedenceover the attributes supplied in the client configuration. | No |
httpApiSpec | HTTPAPISpec[] | HTTP API specifications to generate API attributes. | No |
quotaSpec | QuotaSpec[] | Quota specifications to generate quota requirements. | No |
networkFailPolicy | NetworkFailPolicy | Specifies the behavior when the client is unable to connect to Mixer.This is the service-level policy. It overrides[mesh-levelpolicy][istio.mixer.v1.config.client.TransportConfig.network_fail_policy]. | No |
forwardAttributes | Attributes | Default attributes to forward to upstream. This typicallyincludes the “source.ip” and “source.uid” attributes.In case of a per-route override, per-route attributes take precedenceover 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 forwardedattributes. 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 |
StringMatch
Describes how to match a given string in HTTP headers. Match iscase-sensitive.
Field | Type | Description | Required |
---|---|---|---|
exact | string (oneof) | exact string match | Yes |
prefix | string (oneof) | prefix-based match | Yes |
regex | string (oneof) | ECMAscript style regex-based match | Yes |
TcpClientConfig
Defines the client config for TCP.
Field | Type | Description | Required |
---|---|---|---|
transport | TransportConfig | The transport config. | No |
mixerAttributes | Attributes | Default attributes to send to Mixer in both Check andReport. This typically includes “destination.ip” and“destination.uid” attributes. | No |
disableCheckCalls | bool | If set to true, disables Mixer check calls. | No |
disableReportCalls | bool | If set to true, disables Mixer check calls. | No |
connectionQuotaSpec | QuotaSpec | Quota specifications to generate quota requirements.It applies on the new TCP connections. | No |
reportInterval | Duration | Specify report interval to send periodical reports for long TCPconnections. If not specified, the interval is 10 seconds. This intervalshould not be less than 1 second, otherwise it will be reset to 1 second. | No |
TransportConfig
Defines the transport config on how to call Mixer.
Field | Type | Description | Required |
---|---|---|---|
disableCheckCache | bool | The flag to disable check cache. | No |
disableQuotaCache | bool | The flag to disable quota cache. | No |
disableReportBatch | bool | The flag to disable report batch. | No |
networkFailPolicy | NetworkFailPolicy | 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 |
statsUpdateInterval | Duration | Specify refresh interval to write Mixer client statistics to Envoy sharememory. If not specified, the interval is 10 seconds. | No |
checkCluster | string | Name of the cluster that will forward check calls to a pool of mixerservers. Defaults to “mixer_server”. By using different names forcheckCluster and reportCluster, it is possible to have one set ofMixer servers handle check calls, while another set of Mixer servershandle report calls.NOTE: Any value other than the default “mixer_server” will require theIstio Grafana dashboards to be reconfigured to use the new name. | No |
reportCluster | string | Name of the cluster that will forward report calls to a pool of mixerservers. Defaults to “mixer_server”. By using different names forcheckCluster and reportCluster, it is possible to have one set ofMixer servers handle check calls, while another set of Mixer servershandle report calls.NOTE: Any value other than the default “mixer_server” will require theIstio Grafana dashboards to be reconfigured to use the new name. | No |
attributesForMixerProxy | Attributes | Default attributes to forward to Mixer upstream. This typicallyincludes the “source.ip” and “source.uid” attributes. Theseattributes are consumed by the proxy in front of mixer. | No |
reportBatchMaxEntries | uint32 | When disable_report_batch is false, this value specifies the maximum numberof requests that are batched in report. If left unspecified, the default valueof report_batch_max_entries == 0 will use the hardcoded defaults ofistio::mixerclient::ReportOptions. | No |
reportBatchMaxTime | Duration | When disable_report_batch is false, this value specifies the maximum elapsedtime a batched report will be sent after a user request is processed. If leftunspecified, the default report_batch_max_time == 0 will use the hardcodeddefaults of istio::mixerclient::ReportOptions. | No |
istio.mixer.v1.Attributes
Attributes represents a set of typed name/value pairs. Many of Mixer’sAPI 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 theenvironment this traffic occurs in. An Istio attribute carries a specific pieceof information such as the error code of an API request, the latency of an API request, or theoriginal 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 usedin the deployment. The primary attribute producer in Istio is Envoy, althoughspecialized Mixer adapters and services can also generate attributes.
The common baseline set of attributes available in most Istio deployments is definedhere.
Attributes are strongly typed. The supported attribute types are defined byValueType.Each type of value is encoded into one of the so-called transport types presentin 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.
Field | Type | Description | Required |
---|---|---|---|
attributes | map<string, AttributeValue> | A map of attribute name to its value. | No |