Kind | Group | Version | Description |
---|---|---|---|
TykOasApiDefinition | tyk.tyk.io | v1alpha1 | Defines configuration of Tyk OAS API Definition object |
ApiDefinition | tyk.tyk.io | v1alpha1 | Defines configuration of Tyk Classic API Definition object |
TykStreamsApiDefinition | tyk.tyk.io | v1alpha1 | Defines configuration of Tyk Streams |
SecurityPolicy | tyk.tyk.io | v1alpha1 | Defines configuration of security policies. Operator supports linking ApiDefinition custom resources in SecurityPolicy’s access list so that API IDs do not need to be hardcoded in the resource manifest. |
SubGraph | tyk.tyk.io | v1alpha1 | Defines a GraphQL federation subgraph. |
SuperGraph | tyk.tyk.io | v1alpha1 | Defines a GraphQL federation supergraph. |
OperatorContext | tyk.tyk.io | v1alpha1 | Manages the context in which the Tyk Operator operates, affecting its overall behavior and environment. See Operator Context for details. |
Kind | Group | Version | Description |
---|---|---|---|
APIDescription | tyk.tyk.io | v1alpha1 | Configures Portal Documentation. |
PortalAPICatalogue | tyk.tyk.io | v1alpha1 | Configures Portal API Catalogue. |
PortalConfig | tyk.tyk.io | v1alpha1 | Configures Portal Configuration. |
A Kubernetes operator is an application-specific controller that extends the functionality of the Kubernetes API to create, configure, and manage instances of complex applications on behalf of a Kubernetes user.
v1alpha1
version, no breaking changes will be introduced to existing Custom Resources without a version bump. This means that any significant changes or updates that could impact existing resources will result in a new version (e.g., v1beta1
or v1
) and Operator will continue supporting all CRD versions for a reasonable time before deprecating an older version. This ensures a smooth transition and compatibility, allowing you to upgrade without disrupting your current configurations and workflows.
For more details on Kubernetes CRD versioning practices, refer to the Kubernetes Custom Resource Definition Versioning documentation.
tyk-operator-conf
secret or from the environment variables (listed in the table below).
Key or Environment Variable | Description |
---|---|
TYK_MODE | ”ce” for OSS or “pro” for licensed users |
TYK_URL | URL of Tyk Gateway or Dashboard API |
TYK_ORG | Organization ID of Operator user |
TYK_AUTH | API key of Operator user |
OperatorContext
in Tyk Operator allows you to create isolated management environments by defining specific access parameters for different teams or departments within a shared Tyk Operator instance. It helps you specify:
OperatorContext
configurations, you can define unique access and management contexts for different teams. These contexts can then be referenced directly in your ApiDefinition
, TykOasApiDefinition
, TykStreamsApiDefinition
or SecurityPolicy
custom resource definitions (CRDs) using the contextRef
field, enabling precise control over API configurations.
OperatorContext
is defined, Tyk Operator defaults to using credentials from the tyk-operator-conf
secret or from environment variables. This means all API management actions are performed under the system’s default user credentials, with no specific contextual isolation.OperatorContext
is defined but not referenced in an API configuration, Tyk Operator continues to use the default credentials from tyk-operator-conf
. The specified OperatorContext
is ignored, resulting in API operations being managed under default credentials.OperatorContext
is both defined and referenced in an API or policy, Tyk Operator utilizes the credentials and parameters from the referenced OperatorContext
to perform API operations. This allows each API or policy to be managed with isolated configurations, enabling team-based or department-specific API management within the same Kubernetes cluster.OperatorContext
offers flexibility for multi-tenancy, helping organizations manage and isolate API configurations based on their specific team or departmental needs.
Certificate Type | Supported in ApiDefinition | Supported in TykOasApiDefinition | Supported in TykStreamsApiDefinition |
---|---|---|---|
Client certifates | ✅ Client mTLS | ✅ Client mTLS | Certificate ID can be set in the API Definition but configuring certificates from Secrets in CRD is not supported. |
Custom domain certificates | ✅ TLS and SSL | ✅ TLS and SSL | Certificate ID can be set in the API Definition but configuring certificates from Secrets in CRD is not supported. |
Public keys pinning | ✅ Certificate pinning | ✅ Certificate pinning | Certificate ID can be set in the API Definition but configuring certificates from Secrets in CRD is not supported. |
Upstream mTLS | ✅ Upstream mTLS via Operator | ✅ Upstream mTLS via Operator | Certificate ID can be set in the API Definition but configuring certificates from Secrets in CRD is not supported. |
allow_explicit_policy_id
and
enable_duplicate_slugs
set to true
and Gateway must have policies.allow_explicit_policy_id
set to true
.
Tyk Operator needs a user credential to connect with
Tyk Dashboard. The Operator user should have write access to the resources it is going to manage, e.g. APIs, Certificates,
Policies, and Portal. It is the recommended practice to turn off write access for other users for the above resources. See
Using Tyk Operator to enable GitOps with Tyk about
maintaining a single source of truth for your API configurations.
cert-manager
requirement. For more details, please refer to this configuration.
global.components.operator
to true
.
Starting from Tyk Operator v1.0, a license key is required to use the Tyk Operator. You can provide it while installing
Tyk Stack, Tyk Control Plane or Tyk OSS helm chart by setting global.license.operator
field. You can also set license
key via a Kubernetes secret using global.secrets.useSecretName
field. The secret should contain a key called
OperatorLicense
Note: If you are using global.secrets.useSecretName
, you must configure the operator license in the referenced Kubernetes secret. global.license.operator
will not be used in this case.
envVars
field of helm chart. See the table below for a list of expected
environment variable names and example values.
tyk-operator-conf
. If you want to use
another name, configure it through Helm Chart envFrom value.
The Kubernetes secret or envVars field should set the following keys:
Key | Mandatory | Example Value | Description |
---|---|---|---|
TYK_OPERATOR_LICENSEKEY | Yes | <JWT_ENCODED_LICENSE_KEY> | Tyk Operator license key |
TYK_MODE | Yes | pro | “ce” for Tyk Open Source mode, “pro” for Tyk licensed mode. |
TYK_URL | Yes | http://dashboard-svc-tyk-tyk-dashboard.tyk.svc:3000 | Management URL of Tyk Gateway (Open Source) or Tyk Dashboard |
TYK_AUTH | Yes | 2d095c2155774fe36d77e5cbe3ac963b | Operator user API key. |
TYK_ORG | Yes | 5e9d9544a1dcd60001d0ed20 | Operator user ORG ID. |
TYK_TLS_INSECURE_SKIP_VERIFY | No | true | Set to “true” if the Tyk URL is HTTPS and has a self-signed certificate. If it isn’t set, the default value is false . |
WATCH_NAMESPACE | No | foo,bar | Comma separated list of namespaces for Operator to operate on. The default is to operate on all namespaces if not specified. |
WATCH_INGRESS_CLASS | No | customclass | Define the ingress class Tyk Operator should watch. Default is tyk |
TYK_HTTPS_INGRESS_PORT | No | 8443 | Define the ListenPort for HTTPS ingress. Default is 8443 . |
TYK_HTTP_INGRESS_PORT | No | 8080 | Define the ListenPort for HTTP ingress. Default is 8080 . |
tyk-operator-conf
will have been created with the following keys:
TYK_OPERATOR_LICENSEKEY, TYK_AUTH, TYK_MODE, TYK_ORG
, and TYK_URL
by default. If you didn’t use Helm Chart for
installation, please prepare tyk-operator-conf
secret yourself using the commands below:
TYK_AUTH
corresponds
to Tyk Dashboard API Access Credentials. TYK_ORG
corresponds to Organization ID.tyk-operator-conf
are ever changed or updated, the tyk-operator-controller-manager
pod must be restarted to pick up these changes.WATCH_NAMESPACE
through tyk-operator-conf
secret or the environment variable to a comma separated list
of k8s namespaces. For example:
WATCH_NAMESPACE=""
will watch for resources across the entire cluster.WATCH_NAMESPACE="foo"
will watch for resources in the foo
namespace.WATCH_NAMESPACE="foo,bar"
will watch for resources in the foo
and bar
namespace.tyk
in Ingress resources kubernetes.io/ingress.class
annotation
and will ignore all other ingress classes. If you want to override this default behavior, you may do so by setting
WATCH_INGRESS_CLASS through tyk-operator-conf
or the environment variable.
tyk-operator-system
namespace.
Helm configurations
webhookPort
is deprecated in favor of webhooks.port
.Key | Type | Default |
---|---|---|
envFrom[0].secretRef.name | string | "tyk-operator-conf" |
envVars[0].name | string | "TYK_OPERATOR_LICENSEKEY" |
envVars[0].value | string | "{OPERATOR_LICENSEKEY}" |
envVars[1].name | string | "TYK_HTTPS_INGRESS_PORT" |
envVars[1].value | string | "8443" |
envVars[2].name | string | "TYK_HTTP_INGRESS_PORT" |
envVars[2].value | string | "8080" |
extraVolumeMounts | list | [] |
extraVolumes | list | [] |
fullnameOverride | string | "" |
healthProbePort | int | 8081 |
hostNetwork | bool | false |
image.pullPolicy | string | "IfNotPresent" |
image.repository | string | "tykio/tyk-operator" |
image.tag | string | "v1.0.0" |
imagePullSecrets | list | [] |
metricsPort | int | 8080 |
nameOverride | string | "" |
nodeSelector | object | {} |
podAnnotations | object | {} |
podSecurityContext.allowPrivilegeEscalation | bool | false |
rbac.port | int | 8443 |
rbac.resources | object | {} |
replicaCount | int | 1 |
resources | object | {} |
serviceMonitor | bool | false |
webhookPort | int | 9443 |
webhooks.enabled | bool | true |
webhooks.port | int | 9443 |
webhooks.annotations | object | {} |
webhooks.tls.useCertManager | bool | true |
webhooks.tls.secretName | string | webhook-server-cert |
webhooks.tls.certificatesMountPath | string | /tmp/k8s-webhook-server/serving-certs |
TYK_OPERATOR_LICENSEKEY
. Populate this field
with your Tyk Operator license key.
To configure the license key:
tyk-operator-conf
).TYK_OPERATOR_LICENSEKEY
to this Secret.TYK_OPERATOR_LICENSEKEY
to your Tyk Operator license key.enabled
: Enables or disables webhooks.port
: Specifies the port for webhook communication.annotations
: Allows adding custom annotations.tls.useCertManager
: If true, Cert-Manager will handle TLS certificates.tls.secretName
: The name of the Kubernetes Secret storing the TLS certificate.tls.certificatesMountPath
: Path where the webhook server mounts its certificates.x-tyk-api-gateway
section should be present.
oas-api-definition.json
) locally.
tyk-oas-api-config
in the tyk
namespace (replace tyk
with your actual namespace if different).
kubectl apply
command, you may get an error that the annotation metadata cannot exceed 256KB. It is because by using kubectl apply
, kubectl
automatically saves the whole configuration in the annotation kubectl.kubernetes.io/last-applied-configuration for tracking changes. Your Tyk OAS API Definition may easily exceed the size limit of annotations (256KB). Therefore, kubectl create
is used here to get around the problem.TykOasApiDefinition
resource to tell the Tyk Operator to use the Tyk OAS API definition stored in the ConfigMap.
Create a manifest file named tyk-oas-api-definition.yaml
with the following content:
kubectl
to apply the TykOasApiDefinition
manifest to your cluster:
TykOasApiDefinition
resource in your cluster. The Tyk Operator will watch for this resource and configures Tyk Gateway or Tyk Dashboard with a new API using the provided Tyk OAS API definition.
/store/inventory"
, you can use curl
or any API client to test it:
kubectl replace
:
kubectl replace
without --save-config
option is used here instead of kubectl apply
because we do not want to save the Tyk OAS API definition in its annotation. If you want to enable --save-config
option or use kubectl apply
, the Tyk OAS API definition size would be further limited to at most 262144 bytes.ConfigMap
is created that contains the Tyk OAS API Definition with the data
field with key test_oas.json
. This is linked to from a TykOasApiDefinition
resource via spec.tykOAS.configmapRef
.
To apply it, simply save the manifest into a file (e.g., tyk-oas-api.yaml
) and use kubectl apply -f tyk-oas-api.yaml
to create the required resources in your Kubernetes cluster. This command will create the necessary ConfigMap and TykOasApiDefinition resources in the default
namespace.
oas-api-definition.json
and created a ConfigMap named tyk-oas-api-config
in the tyk
namespace.
Modify your Tyk OAS API Definition oas-api-definition.json
as follow.
components.securitySchemes
defines the authentication method (in this case, apiKey
in the header).security
: Applies the authentication globally to all endpoints.x-tyk-api-gateway.server.authentication
: Tyk-specific extension to enable the authentication scheme.oas-api-definition.json
.
tyk-oas-api-config
in the tyk
namespace (replace tyk
with your actual namespace if different) with the new Tyk OAS API Definition stored in oas-api-definition.json
.
Since a TykOasApiDefinition
resource has been created with reference to this ConfigMap in the previous tutorial:
TykOasApiDefinition
has been updated successfully:
latestTransaction
field in status
:
time
field.
/store/inventory"
, you can use curl
or any API client to test it:
401 Unauthorized
response now as an API key is required for access. Your API has been secured by Tyk Gateway.
httpbin.yaml
, then add the following:
httpbin
, as specified in spec.name
field, which listens to path /httpbin
and proxies requests to http://httpbin.org, as specified under spec.proxy
field. Now, any requests coming to the /httpbin
endpoint will be proxied to the target URL that we defined in spec.proxy.target_url
, which is http://httpbin.org in our example.
You can visit the ApiDefinition CRD page to see all the latest API Definitions fields and features we support.
proxy.target_url
as a Kubernetes Service following DNS for Services and Pods guideline, so that the requests will be proxied to your service.
In general, Kubernetes Services have a <service-name>.<namespace-name>
.svc.cluster.local DNS entry once they are created.
For example, if you have a service called httpbin
in default
namespace, you can contact httpbin
service with httpbin.default.svc
DNS record in the cluster, instead of IP addresses.
Please visit the official Kubernetes documentation for more details.
Suppose you want to create a Deployment of httpbin service using ci/upstreams/httpbin.yaml file. You are going to expose the application through port 8000
as described under the Service specification.
You can create Service and Deployment by either applying the manifest defined in our repository:
1/1
and STATUS Running
state.
Once the pod is ready, you can update your httpbin
API’s target_url
field to proxy your requests to the Service that you created above.
You can check all services in the <ns>
namespace as follows:
httpbin
as follows:
spec.proxy.target_url
field.
It is set to http://httpbin.default.svc:8000
by following the convention described above (<service_name>.<namespace>.svc:<service_port>
).
Now, if you send your request to the /httpbin
endpoint of the Tyk Gateway, the request will be proxied to the httpbin Service
:
httpbin.default.svc:8000
.
httpbin
API is keyless. If you check the APIDefinition’s specification, the use_keyless
field is set to true
.
Tyk keyless access represents completely open access for your API and causes Tyk to bypass any session-based middleware (middleware that requires access to token-related metadata). Keyless access will enable all requests through.
You can disable keyless access by setting use_keyless
to false.
httpbin.yaml
fileuse_keyless
to false, the default authentication mode is Authentication token.
Now, to access httpbin
API, you need to include a key to the header. Otherwise, you will get a HTTP 401 Unauthorized
response.
httpbin
API now. Follow this guide to see how to create an API key for your installation.
You can obtain the API name and API ID of our example httpbin
API by following command:
name
and status.api_id
field.
In our example, it is as follows:
httpbin
API.
HTTP 401 Unauthorized
response.
Authorization
header of the request. You can customize this behavior by configuring the following fields:
use_cookie
: Set to true to use a cookie value for the token.cookie_name
: Specify the name of the cookie if use_cookie is enabled.use_param
: Set to true to allow the token to be passed as a query parameter.param_name
: Specify the parameter name if use_param is enabled.use_certificate
: Enable client certificate. This allows you to create dynamic keys based on certificates.validate_signature
: Enable signature validation.jwt_signing_method
: Specify the method used to sign the JWT. Refer to JWT Signing Method for supported methods.jwt_source
: Specify the public key used for verifying the JWT.jwt_identity_base_field
: Define the identity source, typically set to sub
(subject), which uniquely identifies the user or entity.jwt_policy_field_name
: Specify the claim within the JWT payload that indicates the policy ID to apply.jwt_default_policies
(Optional): Define default policies to apply if no policy claim is found in the JWT payload.sub
claim as the identity source, uses the pol
claim for policy ID, and assigns a default policy (jwt-policy
SecurityPolicy in default
namespace) if no policy is specified in the token.
httpbin-go-auth
.
For an example of Golang authentication middleware, see Performing custom authentication with a Golang plugin.
httpbin-grpc-auth
.
For a detailed walkthrough on setting up Tyk with gRPC authentication plugins, refer to Extending Tyk with gRPC Authentication Plugins.
base_identity_provided_by
field to one of the supported chained enums. Consult the Multi (Chained) Authentication section for the supported auths.
In this example, we are creating an API definition with basic authentication and mTLS with basic authentication as base identity for httpbin-multiple-authentications
.
enable_ip_whitelisting
: Enables IPs allowlist. When set to true
, only requests coming from the explicit list of IP addresses defined in (allowed_ips
) are allowed through.allowed_ips
: A list of strings that defines the IP addresses (in CIDR notation) that are allowed access via Tyk.enable_ip_blacklisting
: Enables IPs blocklist. If set to true
, requests coming from the explicit list of IP addresses (blacklisted_ips) are not allowed through.blacklisted_ips
: A list of strings that defines the IP addresses (in CIDR notation) that are blocked access via Tyk. This list is explicit and wildcards are currently not supported.403
).
graphql
configuration object. A GraphQL schema is specified within the schema
field and the execution mode is set to proxyOnly
. The GraphQL public playground is enabled with the path set to /playground
.
/httpbin
to target URL http://httpbin.org
.
Traffic routing can be configured under spec.proxy
:
target_url
defines the upstream address (or target URL) to which requests should be proxied.listen_path
is the base path on Tyk to which requests for this API should be sent. Tyk listens out for any requests coming into the host at this path, on the port that Tyk is configured to run on and processes these accordingly. For example, /api/
or /
or /httpbin/
.strip_listen_path
removes the inbound listen path (as accessed by the client) when generating the outbound request for the upstream service. For example, consider the scenario where the Tyk base address is http://acme.com/
, the listen path is example/
and the upstream URL is http://httpbin.org/
: If the client application sends a request to http://acme.com/example/get
then the request will be proxied to http://httpbin.org/example/get
spec.domain
is the domain to bind this API to. This enforces domain matching for client requests.
In this example, requests to httpbin.tyk.io
will be proxied to upstream URL http://httpbin.org
6380
to tcp://localhost:6379
.
TykStreamsApiDefinition
resource.
x-tyk-api-gateway
extension for Tyk-specific settings.x-tyk-streaming
extension for Tyk Streams configuration.TykStreamsApiDefinition
custom resource.
Example manifest:
kubectl
command to apply the TykStreamsApiDefinition
manifest to your Kubernetes cluster:
TykStreamsApiDefinition
resource. The Tyk Operator watches this resource and configures the Tyk Gateway or Tyk Dashboard with the new API.
TykStreamsApiDefinition
resource to ensure that the API has been successfully created:
ConfigMap
. The Tyk Operator will automatically detect changes and update the API in the Tyk Gateway.
SecurityPolicy
CRD. The following example illustrates how to configure a default policy for trial users for a Tyk Classic API named httpbin
, a Tyk OAS API named petstore
, and a Tyk Streams API named http-to-kafka
.
trial-policy.yaml
In this example, we have defined a security policy as described below:
Define Security Policy status and metadata
name
: A descriptive name for the security policy.
active
: Marks the policy as active (true or false).
state
: The current state of the policy. It can have one of three values:
active
: Keys connected to this policy are enabled and new keys can be created.draft
: Keys connected to this policy are disabled; no new keys can be created.deny
: Policy is not published to Gateway; no keys can be created.tags
: A list of tags to categorize or label the security policy, e.g.
meta_data
: Key-value pairs for additional metadata related to the policy, e.g.
access_rights_array
: Defines the list of APIs that the security policy applies to and the versions of those APIs.
name
: The Kubernetes metadata name of the API resource to which the policy grants access.namespace
: The Kubernetes namespace where the API resource is deployed.kind
: Tyk OAS APIs (TykOasApiDefinition
), Tyk Streams (TykStreamsApiDefinition
) and Tyk Classic APIs (ApiDefinition
) can be referenced here. The API format can be specified by kind
field. If omitted, ApiDefinition
is assumed.versions
: Specifies the API versions the policy will cover. If the API is not versioned, include the default version here. The default version of a Classic API is “Default”. The default version of a Tyk OAS API is "".ApiDefinition
resource named httpbin
in the default
namespace, a TykOasApiDefinition
resource named petstore
in the default
namespace, and a TykStreamsApiDefinition
resource named http-to-kafka
in the default
namespace. Note that with Tyk Operator, you do not need to specify API ID as in the raw Policy definition. Tyk Operator will automatically retrieve the API ID of referenced API Definition resources for you.
Define Rate Limits, Usage Quota, and Throttling
rate
: The maximum number of requests allowed per time period (Set to -1
to disable).per
: The time period (in seconds) for the rate limit (Set to -1
to disable).throttle_interval
: The interval (in seconds) between each request retry (Set to -1
to disable).throttle_retry_limit
: The maximum number of retry attempts allowed (Set to -1
to disable).quota_max
: The maximum number of requests allowed over a quota period (Set to -1
to disable).quota_renewal_rate
: The time, in seconds, after which the quota is renewed.httpbin
API at a rate limit of maximum 120 times per 60 seconds ("rate": 120, "per": 60
), with a usage quota of 1000 every hour ("quota_max": 1000, "quota_renewal_rate": 3600
), without any request throttling (throttle_interval: -1, throttle_retry_limit: -1
).
kubectl apply
command:
status
field, you can see that this security policy has been linked to httpbin
, petstore
, and http-to-kafka
APIs.
limit
field for that API.
The following manifest defines a security policy with per-API rate limits and quotas for two APIs: httpbin
and petstore
.
httpbin
API:
petstore
API:
httpbin
and petstore
.
allowed_urls
field under access_rights_array
.
The following manifest defines a security policy that allows access only to specific URLs and HTTP methods for two APIs: httpbin
(a Tyk Classic API) and petstore
(a Tyk OAS API).
curl -H "Authorization: Bearer $KEY_AUTH" http://tyk-gw.org/petstore/pet/10
returns a 200 OK
response.curl -H "Authorization: Bearer $KEY_AUTH" http://tyk-gw.org/httpbin/get
returns a 200 OK
response.curl -H "Authorization: Bearer $KEY_AUTH" http://tyk-gw.org/petstore/pet
returns a 403 Forbidden
response with the message:curl -H "Authorization: Bearer $KEY_AUTH" http://tyk-gw.org/httpbin/anything
returns a 403 Forbidden
response with the message:partitions
field:
quota
: Set to true to enforce quota rules (limits the number of requests allowed over a period).rate_limit
: Set to true to enforce rate limiting rules (limits the number of requests per second or minute).acl
: Set to true to enforce access control rules (controls which APIs or paths can be accessed).complexity
: Set to true to enforce GraphQL complexity rules (limits the complexity of GraphQL queries to prevent resource exhaustion).api_id
from your API Definition to the YAML of your ApiDefinition
type. Then, the Operator will take care of the rest.
Example:
spec.api_id
field:5f8f3933f56e1a5ffe2cd58c
5f8f3933f56e1a5ffe2cd58c
into the YAML’s spec.id
field like below
spec.access_rights_array
field of the YAML must refer to the ApiDefinition object that the policy identified by the id will affect.
To find available ApiDefinition objects:
id
field as above, allowing keys to continue to work as before the delete event.
api_id
, this gives us the ability to preserve Keys that are tied to APIs or policies which are tied to APIs.
Imagine any use case where you have keys tied to policies, and policies tied to APIs.
Now imagine that these resources are unintentionally destroyed. Our database goes down, or our cluster, or something else.
Well, using the Tyk Operator, we can easily re-generate all our resources in a non-destructive fashion. That’s because the operator intelligently constructs the unique ID using the unique namespaced name of our CRD resources. For that reason.
Alternatively, if you don’t explicitly state it, it will be hard-coded for you by Base64 encoding the namespaced name of the CRD.
For example:
httpbin
API that was previously created.
apidesc.yaml
, then add the following;
api_portal.yaml
, then add the following:
apis
.
doc_type: swagger
documentation
: Base64 encoded swagger docdoc_type: swagger_custom_url
documentation
: The URL to the swagger documentation, for example “https://httpbin.org/spec.json”doc_type: graphql
myingress.do.poc.tyk.technology
, as defined by the host
field in the Ingress rule.httpbin-ingress-tls
uploaded to Tyk and certificates field set to the resulting certificate ID./httpbin
, which is defined by the path
field in the Ingress rule.http://httpbin.default.svc:8000
, which corresponds to the backend service defined in the Ingress (httpbin
service running on port 8000
).ApiDefinition
or TykOasApiDefinition
resource. These resources provide a reference configuration that includes details on how the API should be managed, such as security policies, traffic controls, and transformations.
In the given example, there are two important annotations in the Ingress metadata:
myapideftemplate
in the same namespace as the reference for API configuration. The tyk.io/template-kind
annotation indicates that this reference is of type ApiDefinition
. Alternatively, it could be a TykOasApiDefinition
, depending on the user’s choice. Tyk Operator detects these annotations and looks for the specified resource in the same namespace. For each path defined in the Ingress, Tyk Operator creates a corresponding API in Tyk by copying the specification from myapideftemplate
resource (such as authentication type, rate limiting, etc.) and then updates only the relevant fields like custom domain, certificates, listen path, and upstream URL based on the Ingress spec.
Note that ApiDefinition
or TykOasApiDefinition
created for use as a template for Ingress resources should have a special label set so that Tyk Operator would not manage it as ordinary APIs. Here is the required label for ApiDefinition
and TykOasApiDefinition
respectively:
Label for ApiDefinition
indicating it is a resource template.
TykOasApiDefinition
indicating it is a resource template.
TykStreamsApiDefinition
as resource template is not supported.
TykOasApiDefinition
resource or ApiDefinition
resource and then let Tyk Operator creates all the APIs from your existing Ingress rules using the referenced resource as template, streamlining the transition process.
Additionally, the Tyk Operator also handles any changes to the Ingress resources it manages. If an Ingress resource is updated — whether through the addition, removal, or modification of paths in the Ingress rules — Tyk Operator automatically reconfigures the corresponding Tyk APIs to ensure they remain in sync with the updated Ingress configuration. This dynamic updating capability ensures that your API management remains consistent and up-to-date with the latest changes in your Kubernetes environment.
tyk
in the Ingress resource. You can also optionally create a ApiDefinition
or TykOasApiDefinition
resource template that provides default API configurations. This allows Tyk Operator to read the Ingress resource and create API Definition resources based on ingress path and referenced template.
The following sections shows some example of Tyk ApiDefinition
or TykOasApiTemplate
template and Ingress specification.
kubernetes.io/ingress.class
annotation identifies the IngressClass that will process Ingress objects.
Tyk Operator by default looks for the value tyk
and will ignore all other ingress classes. If you wish to override this default behavior,
you may do so by setting the environment variable WATCH_INGRESS_CLASS
in the operator manager deployment. See Installing Tyk Operator for further information.
default-httpbin-ingress-78acd160d
inside Tyk’s Gateway.
ApiDefinition’s name comes from:
default
: The namespace of this Ingress resource,httpbin-ingress
: The name of this Ingress resource,78acd160d
: Short hash (first 9 characters) of Host (""
) and Path (/httpbin
). The hash algorithm is SHA256.ImplementationSpecific
, Exact
, and Prefix
. Currently, not all path types are supported. The below table shows the unsupported path types for Sample HTTP Ingress Resource based on the examples in the Kubernetes Ingress documentation.
Kind | Path(s) | Request path(s) | Expected to match? | Works as Expected |
---|---|---|---|---|
Exact | /foo | /foo/ | No | No. |
Prefix | /foo/ | /foo, /foo/ | Yes | No, /foo/ matches, /foo does not match. |
Prefix | /aaa/bb | /aaa/bbb | No | No, the request forwarded to service. |
Prefix | /aaa/bbb/ | /aaa/bbb | Yes, ignores trailing slash | No, /aaa/bbb does not match. |
Prefix | /aaa/bbb | /aaa/bbbxyz | No, does not match string prefix | No, the request forwarded to service. |
proxy.strip_listen_path
is set to true on API Definition, Tyk strips the listen-path (for example, the listen-path for the Ingress under Sample HTTP Ingress Resource is /httpbin) with an empty string.
The following table shows an example of path matching if the listen-path is set to /httpbin
or /httpbin/
.
Kind | Path(s) | Request path(s) | Matches? |
---|---|---|---|
Exact | /httpbin | /httpbin, /httpbin/ | Yes. The request forwarded as / to your service. |
Prefix | /httpbin | /httpbin, /httpbin/ | Yes. The request forwarded as / to your service. |
ImplementationSpecific | /httpbin | /httpbin, /httpbin/ | Yes. The request forwarded as / to your service. |
Exact | /httpbin | /httpbinget, /httpbin/get | Yes. The request forwarded as /get to your service. |
Prefix | /httpbin | /httpbinget, /httpbin/get | Yes. The request forwarded as /get to your service. |
ImplementationSpecific | /httpbin | /httpbinget, /httpbin/get | Yes. The request forwarded as /get to your service. |
Exact | /httpbin/ | /httpbin/, /httpbin/get | Yes. The request forwarded as /get to your service. |
Prefix | /httpbin/ | /httpbin/, /httpbin/get | Yes. The request forwarded as /get to your service. |
ImplementationSpecific | /httpbin/ | /httpbin/, /httpbin/get | Yes. The request forwarded as /get to your service. |
Exact | /httpbin/ | /httpbin | No. Ingress cannot find referenced service. |
Prefix | /httpbin/ | /httpbin | No. Ingress cannot find referenced service. |
ImplementationSpecific | /httpbin/ | /httpbin | No. Ingress cannot find referenced service. |
schema
and sdl
values for your subgraph.
To create a Subgraph API in Tyk, you can reference the subgraph’s metadata name through graphql.graph_ref
field, as follows:
graphql.execution_mode
must be set to subgraph
,graphql.graph_ref
must be set to the metdata name of the SubGraph resource that you would like to refer.subgraph_refs
and schema
values for your supergraph. subgraph_refs
is an array of SubGraph Custom Resource(CR) references which expects the name and namespace of the referenced subgraph. If namespace
is not specified, Operator will check SubGraphs in the current namespace.
Tyk Operator will update your SuperGraph ApiDefinition when one of the subgraphs that you reference in subgraph_refs
changes.
To create a SuperGraph API in Tyk, you can reference the supergraph’s metadata name through graphql.graph_ref field
, as follows:
graphql.execution_mode
must be set to supergraph
,graphql.graph_ref
must be set to the metdata name of the SuperGraph resource that you would like to refer.username
field from the Users SubGraph.
Also, the Supergraph called Social Media already uses the Users Subgraph.
To achieve this, the developer should update the Users SubGraph CRD. Once the SubGraph CRD is updated, Tyk Operator will:
graph_ref
field.
subgraph_ref
.
Phase | Description | Config Value |
---|---|---|
Pre | Occurs before main request processing. | pre |
Auth | Custom authentication can be handled during this phase. | auth_check |
Post Auth | Occurs after key authentication | post_key_auth |
Post | Occurs after the main request processing but before the response is sent. | post |
Response | Occurs after the main request processing but before the response is sent. | response |
custom_middleware
section of the API definition above we can see that there are Golang custom authentication
(auth_check
), post authentication (post_key_auth
), post, pre and response plugins configured.
It can be seen that each plugin is configured with the specific function name and associated source file path of the
file that contains the function. Furthermore, each lifecycle phase can have a list of plugins configured, allowing for
complex processing workflows. For example, you might develop one plugin for logging and another for modifying the
request in the pre request phase.
The driver
configuration parameter describes the plugin implementation language. Please refer to the supported
languages section for list of supported plugin driver names.
Each plugin can have additional settings, such as:
raw_body_only
: When true, indicates that only the raw body should be processed.require_session
: When true, indicates that session metadata will be available to the plugin. This is applicable only
for post, post authentication and response plugins./opt/tyk-gateway/middleware/example-javascript-middleware.js
driver
configuration parameter is set to otto
at line 15, since our plugin is a Javascript plugin. For other
valid values please refer to the plugins driver page.
name
and path
for our plugin. The plugin
configuration block identifies the “hook” or phase in the API request lifecycle when Tyk Gateway will execute the
plugin. In the example above the configuration block is for a pre
request plugin that will be executed before any
middleware. Valid values are the same as the Tyk Classic API Definition equivalent, i.e.
pre
, auth_check
, post
, post-auth
and response
. We can see that the following fields are set within the pre
plugin hook configuration object:
name
field represents the name of the function that implements the plugin in your source code. For Javascript
plugins this must match the name of the middleware object that was created. In the example above we created the
middleware object, exampleJavaScriptMiddlewarePreHook
, by calling
var exampleJavaScriptMiddlewarePreHook = new TykJS.TykMiddleware.NewMiddleware({});
.path
field contains the path to the source file middleware/example-javascript-middleware.js
, relative to the
base installation folder, i.e /opt/tyk-gateway
."Hello: World"
should be injected by the custom plugin.
OperatorContext
:
.spec.secretRef
.
In this example, API access key auth
and organization ID org
are not specified in the manifest. They are provided through a Kubernetes secret named tyk-operator-conf
in alpha
namespace. The secret contains keys TYK_AUTH
and TYK_ORG
which correspond to the auth
and org
fields respectively.
secretRef
. The table shows mappings between .spec.env
properties and secret .spec.data
keys. If a value is configured in both the secret and OperatorContext spec.env
field, the value from secret will take precedence.
Secret key | .spec.env |
---|---|
TYK_MODE | mode |
TYK_URL | url |
TYK_AUTH | auth |
TYK_ORG | org |
TYK_TLS_INSECURE_SKIP_VERIFY | insecureSkipVerify |
TYK_USER_OWNERS (comma separated list) | user_owners |
TYK_USER_GROUP_OWNERS (comma separated list) | user_group_owners |
OperatorContext
is defined, you can reference it in your API Definition objects using contextRef
. Below is an example:
ApiDefinition
object references the team-alpha
context, ensuring that the configuration is applied within the alpha
organization.
tyk://<API_ID>/<path>
scheme, which requires prior knowledge of the API_ID
. Tyk Operator simplifies the management and transformation of API traffic within Kubernetes environments by abstracting APIs as objects, managing them and dynamically assigning API_ID
s by its Kubernetes metedata name and namespace.
rewrite_to_internal
in url_rewrite
, rewrite_to_internal
in triggers
, and proxy.target_internal
fields respectively with these properties:
path
property specifies the endpoint on the target API where the request should be directed. This is the portion of the URL that follows the domain and is crucial for ensuring that the request reaches the correct resource. For example, setting a value of "/myendpoint"
means that the request will be forwarded to the /myendpoint
path on the target API.
query
property allows you to append additional query parameters to the target URL. These parameters can be used to modify the behavior of the target API or to pass along specific request information. For instance, setting query: "check_limits=true"
will include this query string in the redirected request, potentially triggering special handling by the target API.
target
property identifies the API resource to which the request should be routed. It consists of two components: name
and namespace
. The name
is the identifier of the target API, while the namespace
specifies the Kubernetes namespace where the API resource resides. Together, these elements ensure that Tyk Operator accurately locates and routes the request to the intended API. For example, name: "proxy-api"
and namespace: "default"
direct the request to the proxy-api
resource in the default
namespace.
tyk://<API_ID>/<path>
. This mechanism is essential for routing traffic within a microservices architecture or when managing APIs across different namespaces in Kubernetes. Using this object you can effectively manage and optimize API traffic within your Tyk Gateway.
GET /basic/
requests to an API defined by an ApiDefinition object named proxy-api
in the default
namespace. We want the /basic/
prefix to be stripped from the request path and the redirected path should be of the format /proxy/$1
, where the context variable $1
is substituted with the remainder of the path request. For example GET /basic/456
should become GET /proxy/456
.
In this case we can use a rewrite_to_internal
object to instruct Tyk Operator to automatically generate the API rewrite URL on our behalf for the API identified by name proxy-api
in the default
namespace:
/basic/456
would be matched by the match_pattern
rule /basic/(.*)
for GET
requests specified in the method
field. The 456
part of the URL will be captured and replaces {id}
in the path
field. Tyk Operator will use the rewrite_to_internal
configuration to generate the URL rewrite for the API named proxy-api
in the default
namespace, and update the rewrite_to
field accordingly:
rewrite_to
field has been generated with the value tyk://ZGVmYXVsdC9wcm94eS1hcGk/proxy/$1
where ZGVmYXVsdC9wcm94eS1hcGk
represents the API ID for the proxy-api
API resource in the default
namespace. Notice also that path proxy/$1
is appended to the base URL tyk://ZGVmYXVsdC9wcm94eS1hcGk
and contains the context variable $1
. This will be substituted with the value of {id}
in the path
configuration parameter.
basic-auth-internal
within the default
namespace. Subsequently, we can use a rewrite_to_internal
object as follows:
Authorization
header containing Basic
in the header value.
A rewrite_to_internal
configuration object is used to instruct Tyk Operator to generate a redirect to the API identified by the basic-auth-internal
API resource in the default
namespace. The redirect path will be prefixed with basic
. For example, a basic authentication request to path /
will be redirected to /basic/
.
Tyk Operator will automatically generate a URL Rewrite (rewrite_to
) to redirect the request to the API identified by basic-auth-internal
within the default
namespace as follows:
rewrite_to
field has been generated with the value tyk://ZGVmYXVsdC9iYXNpYy1hdXRoLWludGVybmFs/proxy/$1
where ZGVmYXVsdC9iYXNpYy1hdXRoLWludGVybmFs
represents the API ID for the proxy-api
API resource in the default
namespace. Notice also that path basic/$2
is appended to the base URL tyk://ZGVmYXVsdC9iYXNpYy1hdXRoLWludGVybmFs
and contains the context variable $2
. This will be substituted with the remainder of the request path.
/users
to an API defined by an ApiDefinition object named users-internal-api
in the default
namespace.
In this case we can use a proxy.target_internal
field to instruct Tyk Operator to automatically generate the target URL on our behalf for the API identified by name users-internal-api
in the default
namespace:
target_internal
field references other API resources. This field shares the same properties as those described for rewrite_to_internal
, ensuring consistent configuration.
Tyk Operator will automatically generate the target URL to redirect the request to the API identified by users-internal-api
within the default
namespace as follows:
/entry
path and forward requests upstream to http://example.com
We can see that there is a URL Rewrite rule (url_rewrites
) with two triggers configured to match Basic Authentication and Auth Token requests:
rewrite_to_internal
configuration object is used to instruct Tyk Operator to redirect the request to the BasicAuthInternal API, identified by name basic-auth-internal
in the default
namespace. The request URL is rewritten, modifying the path to /basic/<path>
.rewrite_to_internal
configuration object is used to instruct Tyk Operator to redirect the request to the AuthTokenInternal API, identified by name auth-token-internal
in the default
namespace. The request URL is rewritten, modifying the path to /token/<path>
./basic
and forwards them upstream to http://example.com
.
The API is configured with a URL rewrite rule in url_rewrites
to redirect incoming GET /basic/
requests to the API in the Gateway represented by name proxy-api
in the default
namespace. The /basic/
prefix will be stripped from the request URL and the URL will be rewritten with the format /proxy/$1
. The context variable $1
is substituted with the remainder of the path request. For example GET /basic/456
will become GET /proxy/456
.
Furthermore, a header transform rule is configured within transform_headers
to add the header x-transform-api
with value basic-auth
, to the request.
/token
and forwards them upstream to http://example.com
.
The API is configured with a URL rewrite rule in url_rewrites
to redirect incoming GET /token/
requests to the API in the Gateway represented by name proxy-api
in the default
namespace. The /token/
prefix will be stripped from the request URL and the URL will be rewritten to the format /proxy/$1
. The context variable $1
is substituted with the remainder of the path request. For example GET /token/456
will become GET /proxy/456
.
Furthermore, a header transform rule is configured within transform_headers
to add the header x-transform-api
with value token-auth
, to the request.
/proxy
and forwarding upstream to http://httpbin.org
. The listen path is stripped from the request before it is sent upstream.
This API receives requests forwarded from the internal AuthToken Internal and BasicAuth Internal APIs. Requests will contain the header x-transform-api
with value token-auth
or basic-auth
, depending upon which internal API the request originated from.
x-tyk-api-gateway.info.name
field in Tyk OAS API Definition object.
ApiDefinition
, use the spec.name
string field. This name is displayed on the Tyk Dashboard and should concisely describe what the API represents.
Example:
x-tyk-api-gateway.info.state.active
field in Tyk OAS API Definition object.
spec.active
configuration parameter. When set to true
, this enables the API so that Tyk will listen for and process requests made to the listenPath
.
x-tyk-api-gateway.info.state.internal
field in Tyk OAS API Definition object.
spec.internal
configuration parameter as shown in the example below.
status.id
field. Run the following command to inspect generated API ID of a Tyk OAS API.
ZGVmYXVsdC9wZXRzdG9yZQ
.
status.api_id
field. Run the following command to inspect generated API ID of a Tyk Classic API.
ZGVmYXVsdC90ZXN0
.
x-tyk-api-gateway.info.id
field in Tyk OAS API Definition object.
spec.api_id
field. This way, when you apply the manifest, Tyk Operator will not create a new API in the Dashboard. Instead, it will update the original API with the Kubernetes spec.
Example
12345
will be updated according to the provided spec instead of creating a new API.
categories
field in TykOasApiDefinition
CRD.
Here’s an example:
TykStreamsApiDefinition
CRD.
name
field with a #
qualifier. This will categorize the API in the Tyk Dashboard. See How API categories work to learn about limitations on API names.
Example
x-tyk-api-gateway.versioning
object of the Base API, where the child API’s IDs are specified. In the Kubernetes environment with Tyk Operator, where we reference API resources through its Kubernetes name and namespace, this is not desired. Therefore, we add support for versioning configurations through the field versioning
in TykOasApiDefinition
custom resource definition (CRD).
Here’s an example:
order-api
(v1) and order-api-v2
(v2).
versioning
is configured at order-api
(v1), the Base API, and it has similiar structure as Tyk OAS API Definition:
versioning
: This object configures API versioning for the order-api
.
enabled
: Set to true to enable versioning.name
: an identifier for this version of the API (v1).default
: Specifies the default version (v1), which will be used if no version is specified in the request.location
: Specifies where the version key is expected (in this case, in the header). It can be set to header
or url-param
.key
: Specifies the versioning identifier key (x-api-version
) to identify the version. In this example, the version is determined by an HTTP header named x-api-version
.fallbackToDefault
: When set to true, if an unspecified or invalid version is requested, the default version (v1) will be used.stripVersioningData
: When true, removes versioning identifier (like headers or query parameters) from the upstream request to avoid exposing internal versioning details.urlVersioningPattern
: Specifies a regex that matches the format that you use for the versioning identifier (name) if you are using stripVersioningData and fallBackToDefault with location=url with Tyk 5.5.0 or laterversions
: Defines the list of API versions available:
name
: an identifier for this version of the API (v2).tykOasApiDefinitionRef
: Refers to a separate TykOasApiDefinition resource that represent a new API version.
name
: Kubernetes metadata name of the resource (order-api-v2
).namespace
: Kubernetes metadata namespace of the resource (default
).x-tyk-api-gateway.versioning
object), which typically requires referencing specific API IDs. Instead, the Operator allows you to manage versioning declaratively in the TykOasApiDefinition
CRD, using the versioning
field to specify versions and their Kubernetes references (names and namespaces).
When using the CRD for versioning configuration, you don’t have to worry about knowing or managing the unique API IDs within Tyk. The Tyk Operator handles the actual API definition configuration behind the scenes, reducing the complexity of version management.
In case if there is original versioning information in the base API Definition, the versioning information will be kept and be merged with what is specified in CRD. If there are conflicts between the Tyk OAS API Definition and CRD, we will make use of CRD values as the final configuration.
Tyk Operator would also protect you from accidentally deleting a version of an API that is being referenced by another API, maintaining your API integrity.
TykStreamsApiDefinition
CRD. This can be configured natively in the Tyk Streams API Definition.
ApiDefinition
custom resource definition (CRD). See Tyk Classic versioning for a comprehensive example of configuring API versioning for Tyk Classic API with Tyk Operator.
contextRef
in TykOasApiDefinition
or ApiDefinition
objects to ensure configurations are applied within specific organizations. The provided YAML examples illustrate how to set up these configurations.
OperatorContext
comes into play. Users can define different OperatorContext
objects that act as different agents to connect to Tyk Dashboard. Each OperatorContext
can specify different access parameters, including the user access key and organization it belongs to. Within OperatorContext
, users can specify the IDs of owner users or owner user groups. All APIs managed through that OperatorContext
will be owned by the specified users and user groups, ensuring compliance with Tyk Dashboard’s API ownership model.
OperatorContext
allows Tyk Operator to manage APIs under different ownerships:
OperatorContext
is defined, you can reference it in your Tyk OAS or Tyk Streams API Definition objects using contextRef
. Below is an example with TykOasApiDefinition:
TykOasApiDefinition
object references the team-alpha
context, ensuring that it is managed under the ownership of the specified users and user groups.
contextRef
. Below is an example:
ApiDefinition
object references the team-alpha
context, ensuring that it is managed under the ownership of the specified users and user groups.
tyk-operator-conf
, environment variable, or OperatorContext:The Status subresource in Kubernetes is a specialized endpoint that allows developers and operators to retrieve the real-time status of a specific Kubernetes resource. By querying this subresource, users can efficiently access essential information about a resource’s current state, conditions, and other relevant details without fetching the entire resource, simplifying monitoring and aiding in prompt decision-making and issue resolution.The new status subresource latestTransaction consists of a couple of fields that show the latest result of the reconciliation:
.status.latestTransaction.status
: shows the status of the latest reconciliation, either Successful or Failed;.status.latestTransaction.time
: shows the time of the latest reconciliation;.status.latestTransaction.error
: shows the message of an error if observed in the latest transaction.kubectl describe
or kubectl get
:
.status.latestTransaction
field. As .status.latestTransaction.error
implies, the error is related to SecurityPolicy dependency.
OperatorContext
resources for each installation:
Type | Support | Supported From | Comments |
---|---|---|---|
HTTP | ✅ | v0.1 | Standard HTTP proxy for API requests. |
HTTPS | ✅ | v0.4 | Secure HTTP proxy using SSL/TLS encryption. |
TCP | ✅ | v0.1 | Handles raw TCP traffic, useful for non-HTTP APIs. |
TLS | ✅ | v0.1 | Handles encrypted TLS traffic for secure communication. |
GraphQL - Proxy | ✅ | v0.1 | Proxy for GraphQL APIs, routing queries to the appropriate service. |
Universal Data Graph v1 | ✅ | v0.1 | Supports Universal Data Graph v1 for unified data access. |
Universal Data Graph v2 | ✅ | v0.12 | Supports the newer Universal Data Graph v2 for more advanced data handling. |
GraphQL - Federation | ✅ | v0.12 | Supports GraphQL Federation for querying multiple services as one API. |
Type | Support | Supported From | Comments |
---|---|---|---|
API Name | ✅ | v0.1 | Assign and manage names for your APIs. |
API Status (inactive/active) | ✅ | v0.2 | Toggle API status between active and inactive. |
API Categories | ✅ | v0.1 | Categorize APIs for easier management. |
API ID | ✅ | v0.1 | Assign unique IDs to APIs for tracking and management. |
API Ownership | ✅ | v0.12 | Define ownership of APIs within teams or organizations. |
API Versioning | ✅ | v0.1 | Enable version control for APIs. |
Type | Supported | Supported From | Comments |
---|---|---|---|
Path-Based Proxy | ✅ | v0.1 | Route traffic based on URL path. |
Host-Based Proxy | ✅ | v0.1 | Route traffic based on the request host. |
Target URL | ✅ | v0.1 | Redirect traffic to a specific target URL. |
Type | Supported | Supported From | Comments |
---|---|---|---|
Keyless | ✅ | v0.1 | No authentication required, open access. |
Auth Token | ✅ | v0.1 | Requires an authentication token (Bearer token). |
JWT | ✅️ | v0.5 | Uses JSON Web Tokens for secure authentication. |
OpenID Connect | ❌ | - | Recommended to use JWT for OIDC authentication. |
OAuth2 | ❌ | - | OAuth2 not supported, JWT is recommended. |
Client mTLS | ✅ | v0.11 | Supports static client mutual TLS authentication. |
HMAC | ❌ | - | HMAC authentication is not implemented. |
Basic Authentication | ✅ | v0.12 | Only supports enabling with default metadata. |
Custom Authentication Plugin (Go) | ✅ | v0.11 | Custom authentication plugin written in Go. |
Custom Authentication Plugin (gRPC) | ✅ | v0.1 | Custom authentication plugin using gRPC. |
Multiple Authentication | ✅ | v0.14 | Chain multiple authentication methods. |
IP Allowlist | ✅ | v0.5 | Allows access only from specific IP addresses. |
IP Blocklist | ✅ | v0.5 | Blocks access from specific IP addresses. |
Type | Supported | Supported From | |
---|---|---|---|
Mutual TLS for upstream connectioons | ✅ | v0.9 | Mutual TLS authentication for upstream connections. |
Public Key Certificate Pinning | ✅ | v0.9 | Ensures that the upstream certificate matches a known key. |
Upstream Request Signing using HMAC | ✅ | v1.2.0 | Attach an encrypted signature to requests to verify the gateway as the sender. |
Feature | Supported | Supported From | Comments |
---|---|---|---|
Detailed recording (in Log Browser) | ✅ | v0.4.0 | Records detailed API traffic logs for analysis. |
Config Data | ✅ | v0.8.2 | Stores additional configuration data for APIs. |
Context Variables | ✅ | v0.1 | Enables dynamic context-based variables in APIs. |
Cross Origin Resource Sharing (CORS) | ✅ | v0.2 | Manages CORS settings for cross-domain requests. |
Service Discovery | ⚠️ | - | Service discovery is untested in this version. |
Segment Tags | ✅ | v0.1 | Tags APIs for segmentation across environments. |
Internal API (not exposed by Gateway) | ✅ | v0.6.0 | Internal APIs are not exposed via the Gateway. |
Global (API-level) Header Transform | ✅ | v0.1.0 | Transforms request and response headers at the API level. |
Global (API-level) Rate Limit | ✅ | v0.10 | Sets rate limits globally for APIs. |
Custom Plugins | ✅ | v0.1 | Supports the use of custom plugins for API processing. |
Analytics Plugin | ✅ | v0.16.0 | Integrates analytics plugins for API monitoring. |
Batch Requests | ❌ | - | Batch requests are not supported. |
Custom Analytics Tags (Tag Headers) | ✅ | v0.10.0 | Custom tags for API analytics data. |
Expire Analytics After | ❌ | - | Not supported in this version. |
Do not track Analytics (per API) | ✅ | v0.1.0 | Disable analytics tracking on specific APIs. |
Webhooks | ❌ | - | Webhook support is not available. |
Looping | ✅ | v0.6 | Enables internal looping of API requests. |
Round Robin Load Balancing | ✅ | - | Supports round-robin load balancing across upstream servers. |
Endpoint Middleware | Supported | Supported From | Comments |
---|---|---|---|
Allow list | ✅️ | v0.8.2 | Allows requests only from approved sources. |
Block list | ✅️ | v0.8.2 | Blocks requests from disapproved sources. |
Cache | ✅ | v0.1 | Caches responses to reduce latency. |
Advance Cache | ✅ | v0.1 | Provides advanced caching capabilities. |
Circuit Breaker | ✅ | v0.5 | Prevents service overload by breaking circuits. |
Track Endpoint | ✅ | v0.1 | Tracks API endpoint usage for analysis. |
Do Not Track Endpoint | ✅ | v0.1 | Disables tracking for specific endpoints. |
Enforced Timeouts | ✅ | v0.1 | Ensures timeouts for long-running requests. |
Ignore Authentication | ✅ | v0.8.2 | Bypasses authentication for selected endpoints. |
Internal Endpoint | ✅ | v0.1 | Restricts access to internal services. |
URL Rewrite | ✅️ | v0.1 | Modifies request URLs before processing. |
Validate Request | ✅ | v0.8.2 | Validates incoming requests before forwarding. |
Rate Limit | ❌ | - | Rate limiting is not supported per endpoint. |
Request Size Limit | ✅️ | v0.1 | Limits the size of requests to prevent overload. |
Request Method Transform | ✅ | v0.5 | Modifies HTTP methods for incoming requests. |
Request Header Transform | ✅ | v0.1 | Transforms request headers. |
Request Body Transform | ✅ | v0.1 | Transforms request bodies for processing. |
Request Body JQ Transform | ⚠️ | v0.1 | Requires JQ support on the Gateway Docker image. |
Response Header Transform | ✅ | v0.1 | Transforms response headers. |
Response Body Transform | ✅ | v0.1 | Transforms response bodies. |
Response Body JQ Transform | ⚠️ | v0.1 | Requires JQ support on the Gateway Docker image. |
Mock Response | ✅ | v0.1 | Simulates API responses for testing. |
Virtual Endpoint | ✅ | v0.1 | Allows creation of dynamic virtual endpoints. |
Per-Endpoint Plugin | ❌ | - | Plugin support per endpoint is not available. |
Persist Graphql | ❌ | - | Not supported in this version. |
TykOasApiDefinition
can support all features of the Tyk OAS API definition. You just need to provide the Tyk OAS API definition via a ConfigMap. In addition to managing the CRUD (Create, Read, Update, Delete) of Tyk OAS API resources, the Tyk Operator helps you better manage resources through object linking to Ingress, Security Policies, and certificates stored as Kubernetes secrets. See below for a list of Operator features and examples:
Features | Support | Supported From | Comments | Example |
---|---|---|---|---|
API Category | ✅ | v1.0 | - | Manage API Categories |
API Version | ✅ | v1.0 | - | Manage API versioning |
API Ownership via OperatorContext | ✅ | v1.0 | - | API Ownership |
Client Certificates | ✅ | v1.0 | - | Manage TLS certificate |
Custom Domain Certificates | ✅ | v1.0 | - | Manage TLS certificate |
Public keys pinning | ✅ | v1.0 | - | Manage TLS certificate |
Upstream mTLS | ✅ | v1.0 | - | Manage TLS certificate |
Kubernetes Ingress | ✅ | v1.0 | - | Kubernetes Ingress Controller |
Link with SecurityPolicy | ✅ | v1.0 | - | Protect an API |
TykStreamsApiDefinition
can support all features of Tyk Streams. You just need to provide the Tyk Streams API definition via a ConfigMap. In addition to managing the CRUD (Create, Read, Update, Delete) of Tyk Streams API resources, the Tyk Operator helps you better manage resources through object linking to Security Policies. See below for a list of Operator features and examples:
Features | Support | Supported From | Comments | Example |
---|---|---|---|---|
API Ownership via OperatorContext | ✅ | v1.0 | - | API Ownership |
Link with SecurityPolicy | ✅ | v1.0 | - | Protect an API |
Tyk Version | 3.2 | 4.0 | 4.1 | 4.2 | 4.3 | 5.0 | 5.2 | 5.3 | 5.4 | 5.5 | 5.6 | 5.7 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Tyk Operator v0.13 | Y | Y | ||||||||||
Tyk Operator v0.14 | Y | Y | Y | Y | ||||||||
Tyk Operator v0.14.1 | Y | Y | Y | Y | ||||||||
Tyk Operator v0.15.0 | Y | Y | Y | Y | ||||||||
Tyk Operator v0.15.1 | Y | Y | Y | Y | ||||||||
Tyk Operator v0.16.0 | Y | Y | Y | Y | Y | |||||||
Tyk Operator v0.17.0 | Y | Y | Y | Y | Y | Y | ||||||
Tyk Operator v0.17.1 | Y | Y | Y | Y | Y | |||||||
Tyk Operator v0.18.0 | Y | Y | Y | Y | Y | Y | ||||||
Tyk Operator v1.0.0 | Y | Y | Y | Y | Y | Y | ||||||
Tyk Operator v1.1.0 | Y | Y | Y | Y | Y | Y | Y |
Kubernetes Version | 1.19 | 1.20 | 1.21 | 1.22 | 1.23 | 1.24 | 1.25 | 1.26 | 1.27 | 1.28 | 1.29 | 1.30 |
---|---|---|---|---|---|---|---|---|---|---|---|---|
Tyk Operator v0.13 | Y | Y | Y | Y | Y | Y | Y | |||||
Tyk Operator v0.14 | Y | Y | Y | Y | Y | Y | Y | |||||
Tyk Operator v0.14.1 | Y | Y | Y | Y | Y | Y | Y | |||||
Tyk Operator v0.15.0 | Y | Y | Y | Y | Y | Y | Y | |||||
Tyk Operator v0.15.1 | Y | Y | Y | Y | Y | Y | Y | |||||
Tyk Operator v0.16.0 | Y | Y | Y | Y | Y | Y | Y | |||||
Tyk Operator v0.17.0 | Y | Y | Y | Y | Y | |||||||
Tyk Operator v0.17.1 | Y | Y | Y | Y | Y | |||||||
Tyk Operator v0.18.0 | Y | Y | Y | Y | Y | |||||||
Tyk Operator v1.0.0 | Y | Y | Y | Y | Y | Y | ||||||
Tyk Operator v1.1.0 | Y | Y | Y | Y | Y | Y |
Features | Support | Supported From | Example |
---|---|---|---|
API Access | ✅ | v0.1 | API Access |
Rate Limit, Throttling, Quotas | ✅ | v0.1 | Rate Limit, Throttling, Quotas |
Meta Data & Tags | ✅ | v0.1 | Tags and Meta-data |
Path and Method based permissions | ✅ | v0.1 | Path based permission |
Partitions | ✅ | v0.1 | Partitioned policies |
Per API limit | ✅ | v1.0 | Per API Limit |
Per-Endpoint limit | ✅ | v1.0 | Per Endpoint Limit |