Tyk Control Plane Chart
Last updated: 25 minutes read.
The tyk-control-plane
provides the default deployment of Tyk control plane on a Kubernetes cluster. It will deploy all required Tyk components with the settings provided in the values.yaml file.
What components are deployed with Tyk Control Plane Chart?
It includes:
- Tyk Gateway, an Open Source Enterprise API Gateway (supporting REST, GraphQL, TCP and gRPC protocols).
- Tyk Dashboard, a license based component that provides a graphical management interface and analytics platform for Tyk.
- Tyk MDCB, a license based component that performs management and synchronisation of distributed clusters of Tyk API Gateways.
- Tyk Pump, an analytics purger that moves the data generated by your Tyk nodes to any back-end.
- Tyk Developer Portal, a full-fledged CMS-like system for API providers to publish, monetize and drive the adoption of APIs.
Learn more about Tyk control plane at MDCB components.
By default, this chart installs the following components as sub-charts on a Kubernetes cluster using the Helm package manager.
Component | Enabled by Default | Flag |
---|---|---|
Tyk Gateway | true | n/a |
Tyk Dashboard | true | n/a |
Tyk MDCB | true | n/a |
Tyk Pump | false | global.components.pump |
Tyk Enterprise Developer Portal | false | global.components.devPortal |
Tyk Operator | false | global.components.operator |
To enable or disable each component, change the corresponding enabled flag.
Also, you can set the version of each component through image.tag
. You could find the list of version tags available from Docker hub.
Prerequisites
- Kubernetes 1.19+
- Helm 3+
- Redis should already be installed or accessible by the gateway and dashboard.
- MongoDB or PostgreSQL should already be installed or accessible by dashboard. Please consult the list of supported versions that are compatible with Tyk.
Note
If you want to enable Tyk Developer Portal, please use PostgreSQL. MongoDB is not supported in Developer Portal.
Tyk Control Plane Installations
Installing The Chart
To install the chart from Helm repository in namespace tyk
with the release name tyk-control-plane
, issue the following commands:
helm repo add tyk-helm https://helm.tyk.io/public/helm/charts/
helm repo update
helm show values tyk-helm/tyk-control-plane > values.yaml
For further documentation relating to helm command usage, please refer to the helm docs.
At a minimum, modify values.yaml
for the following settings:
- Set Redis connection details
- Set Mongo or PostgreSQL connection details
- Tyk Dashboard License
- Tyk MDCB License
- If you would like to use Developer Portal, an additional license is required: Tyk Developer Portal License
By default, the chart would expose MDCB service as ClusterIP. If you would like to access the control plane from outside the cluster, please change the service type tyk-mdcb.mdcb.service.type
to NodePort or LoadBalancer.
Then just run:
helm install tyk-control-plane tyk-helm/tyk-control-plane -n tyk --create-namespace -f values.yaml
Follow the installation output to obtain connection details to Tyk MDCB, and use that to configure Tyk Data Planes using tyk-data-plane chart.
Uninstalling The Chart
helm uninstall tyk-control-plane -n tyk
This removes all the Kubernetes components associated with the chart and deletes the release.
Upgrading Chart
helm upgrade tyk-control-plane tyk-helm/tyk-control-plane -n tyk -f values.yaml
Configuration
To get all configurable options with detailed comments, issue the following command:
helm show values tyk-helm/tyk-control-plane > values.yaml
You can update any value in your local values.yaml
file and use -f [filename]
flag to override default values during installation.
Alternatively, you can use --set
flag to set it in Tyk installation. See Using Helm for examples.
To configure Tyk components, users can utilize both config files and environment variables. Notably, environment variables take precedence over config files. To maintain simplicity and consistency, the Tyk Helm Charts deploy components with an empty config file while setting container environment variables based on user-defined values. This approach ensures seamless integration with Kubernetes practices, allowing for efficient management of configurations. For a comprehensive overview of available configurations, please refer to the configuration documentation.
Bootstrapping
By default, the chart executes a bootstrapping job immediately after installation. This process ensures the presence of a valid dashboard license and initializes key components such as tyk-dashboard, tyk-portal, and tyk-operator, enabling them for immediate use.
The bootstrapping job uses three distinct applications acting as Helm chart hooks:
Bootstrapping Component | Description |
---|---|
bootstrap-pre-install |
- Runs as a pre-install hook. - Validates the Tyk Dashboard license key to ensure proper installation prerequisites. |
bootstrap-post-install |
- Executes post-installation. - Sets up an organization and admin user in the Tyk Dashboard. - Creates Kubernetes secrets required by Tyk Operator and Tyk Enterprise Portal. Note: If an existing organization and admin user are found in the database, the bootstrapping job will not set up a new organization and user. The Kubernetes secrets will not contain the expected Org ID or API key. Please update the Secret with existing credentials in this case. |
bootstrap-pre-delete |
- Functions as a pre-delete hook. - Cleans up resources, ensuring no residual configurations remain post-uninstallation. |
Key Notes on Bootstrapping:
- Bootstrapping is triggered only during a
helm install
and does not run during ahelm upgrade
. - If
global.components.bootstrap
is set tofalse
, only the dashboard license check will be performed.
Handling Bootstrapping Failures:
- If the bootstrapping process fails, check the logs from the bootstrap pods to diagnose the issue.
- Once reviewed, you can safely delete the bootstrap pods.
- To re-trigger the bootstrapping process after a failure, you must run
helm uninstall
and start the installation process anew.
Setting Environment Variables
Should any environment variables not be set by the Helm Chart, users can easily add them under the extraEnvs
section within the charts for further customization. Values set under extraEnvs
would take precedence over all configurations.
Example of setting extra environment variable to gateway:
tyk-gateway:
gateway:
extraEnvs:
- name: TYK_GW_LOGLEVEL
value: debug
An example is listed below for setting extra environment variable using ConfigMap data, using gateway:
tyk-gateway:
gateway:
extraEnvs:
- name: CONFIG_USERNAME
valueFrom:
configMapKeyRef:
name: backend-user
key: backend-username
An example is listed below for setting extra environment variable using secret data, using gateway:
tyk-gateway:
gateway:
extraEnvs:
- name: SECRET_USERNAME
valueFrom:
secretKeyRef:
name: backend-user
key: backend-username
In the above example, an extra environment variable SECRET_USERNAME
will be added to the Gateway container, with a value of backend-username
associated with the secret backend-user
. It is useful if you want to access secret data from Tyk Gateway configuration file (tyk.conf) or API definitions.
Set Redis Connection Details (Required)
Tyk uses Redis for distributed rate-limiting and token storage. You may use the Bitnami chart or Tyk’s simple-redis to install chart for POC purpose.
Set the following values after installing Redis:
Name | Description |
---|---|
global.redis.addrs |
Redis addresses |
global.redis.pass |
Redis password in plain text |
global.redis.passSecret.name |
If global.redis.pass is not provided, you can store it in a secret and provide the secret name here |
global.redis.passSecret.keyName |
key name to retrieve redis password from the secret |
Recommended: via Bitnami chart
For Redis you can use these rather excellent charts provided by Bitnami. Copy the following commands to add it:
helm upgrade tyk-redis oci://registry-1.docker.io/bitnamicharts/redis -n tyk --create-namespace --install --version 19.0.2
Note
Please make sure you are installing Redis versions that are supported by Tyk. Please refer to Tyk docs to get list of supported versions.
Follow the notes from the installation output to get connection details and password.
Redis(TM) can be accessed on the following DNS names from within your cluster:
tyk-redis-master.tyk.svc.cluster.local for read/write operations (port 6379)
tyk-redis-replicas.tyk.svc.cluster.local for read-only operations (port 6379)
export REDIS_PASSWORD=$(kubectl get secret --namespace tyk tyk-redis -o jsonpath="{.data.redis-password}" | base64 --decode)
The Redis address as set by Bitnami is tyk-redis-master.tyk.svc.cluster.local:6379
You can reference the password secret generated by Bitnami chart by --set global.redis.passSecret.name=tyk-redis
and --set global.redis.passSecret.keyName=redis-password
, or just set global.redis.pass=$REDIS_PASSWORD
Evaluation only: via simple-redis chart
Another option for Redis, to get started quickly, is to use our simple-redis chart.
Warning
Please note that these provided charts must never be used in production or for anything but a quick start evaluation only. Use Bitnami Redis or Redis Enterprise operator in any other case. We provide this chart, so you can quickly deploy Tyk gateway, but it is not meant for long term storage of data.
helm install redis tyk-helm/simple-redis -n tyk
The Tyk Helm Chart can connect to simple-redis
in the same namespace by default. You do not need to set Redis address and password in values.yaml
.
Set Mongo or PostgreSQL Connection Details (Required)
If you have already installed MongoDB or PostgreSQL, you can set the connection details in global.mongo
and global.postgres
section of values file respectively.
If not, you can use these rather excellent charts provided by Bitnami to install MongoDB or PostgreSQL:
Mongo Installation
helm install tyk-mongo bitnami/mongodb --set "replicaSet.enabled=true" -n tyk --version 15.1.3
Then follow notes from the installation output to get connection details and update them in values.yaml
file.
Note
Bitnami MongoDB image is not supported on darwin/arm64 architecture.
Note
Please make sure you are installing MongoDB versions that are supported by Tyk. Please refer to Tyk docs to get list of supported versions.
Note
Important Note regarding MongoDB:
This helm chart enables the PodDisruptionBudget
for MongoDB with an arbiter replica-count of 1. If you intend to perform system maintenance on the node where the MongoDB pod is running and this maintenance requires the node to be drained, then this action will be prevented due to the the replica count being 1.
Increase the replica count in the helm chart deployment to a minimum of 2 to remedy this issue.
Configure global.mongo.mongoURL
and global.storageType
as below. You should replace pass
in the connection string with the MONGODB_ROOT_PASSWORD you obtain from the installation output notes.
global:
# Set mongo connection details if you want to configure mongo pump.
mongo:
# The mongoURL value will allow you to set your MongoDB address.
# Default value: mongodb://mongo.{{ .Release.Namespace }}.svc:27017/tyk_analytics
# mongoURL: mongodb://mongo.tyk.svc:27017/tyk_analytics
# If your MongoDB has a password you can add the username and password to the url
mongoURL: mongodb://root:[email protected]:27017/tyk_analytics?authSource=admin
# mongo-go driver is supported for Tyk 5.0.2+.
# We recommend using the mongo-go driver if you are using MongoDB 4.4.x+.
# For MongoDB versions prior to 4.4, please use the mgo driver.
# Since Tyk 5.3 the default driver is mongo-go.
driver: mongo-go
# Connection URL can also be set using a secret. Provide the name of the secret and key below.
# connectionURLSecret:
# name: ""
# keyName: ""
# Enables SSL for MongoDB connection. MongoDB instance will have to support that.
# Default value: false
useSSL: false
# Choose the storageType for Tyk. [ "mongo", "postgres" ]
storageType: &globalStorageType mongo
PostgreSQL Installation
helm install tyk-postgres bitnami/postgresql --set "auth.database=tyk_analytics" -n tyk --version 12.12.10
Follow the notes from the installation output to get connection details.
Note
Please make sure you are installing PostgreSQL versions that are supported by Tyk. Please refer to Tyk docs to get list of supported versions.
global:
# Postgres connection string parameters.
postgres:
# host corresponds to the host name of postgres
host: tyk-postgres-postgresql.tyk.svc
# port corresponds to the port of postgres
port: 5432
# user corresponds to the user of postgres
user: postgres
# password corresponds to the password of the given postgres user in selected database
password:
# database corresponds to the database to be used in postgres
database: tyk_analytics
# sslmode corresponds to if postgres runs in sslmode (https)
sslmode: disable
# Connection string can also be set using a secret. Provide the name of the secret and key below.
# connectionStringSecret:
# name: ""
# keyName: ""
Protect Confidential Fields with Kubernetes Secrets
In the values.yaml
file, some fields are considered confidential, such as APISecret
, connection strings, etc.
Declaring values for such fields as plain text might not be desired. Instead, for certain fields, Kubernetes secrets can be referenced, and the chart will define container environment variables using secret data.
This section describes how to use Kubernetes secrets to declare confidential fields.
Tyk Dashboard and Developer Portal Admin
If Tyk Dashboard bootstrapping is enabled, the admin user will be created according to the global.adminUser
field.
All admin credentials can also be set through Kubernetes secret.
Note
Once global.adminUser.useSecretName
is declared, it takes precedence over global.adminUser.firstName
,
global.adminUser.lastName
, global.adminUser.email
and global.adminUser.password
.
If global.adminUser.useSecretName
is in use, please add all keys mentioned below to the secret.
Tyk Dashboard Admin First Name
It can be configured via global.adminUser.firstName
as a plain text or Kubernetes secret which includes adminUserFirstName
key in it. Then, this secret must be referenced via global.adminUser.useSecretName
.
Tyk Dashboard Admin Last Name
It can be configured via global.adminUser.lastName
as a plain text or Kubernetes secret which includes adminUserLastName
key in it. Then, this secret must be referenced via global.adminUser.useSecretName
.
Tyk Dashboard and Developer Portal Admin Email
It can be configured via global.adminUser.email
as a plain text or Kubernetes secret which includes adminUserEmail
key in it. Then, this secret must be referenced via global.adminUser.useSecretName
.
Tyk Dashboard and Developer Portal Admin Password
It can be configured via global.adminUser.password
as a plain text or Kubernetes secret which includes adminUserPassword
key in it. Then, this secret must be referenced via global.adminUser.useSecretName
.
APISecret
The global.secrets.APISecret
field configures a header value used in every interaction with Tyk Gateway API.
It can be configured via global.secrets.APISecret
as a plain text or Kubernetes secret which includes APISecret
key in it. Then, this secret must be referenced via global.secrets.useSecretName
.
global:
secrets:
APISecret: CHANGEME
useSecretName: "mysecret" # where mysecret includes `APISecret` key with the desired value.
AdminSecret
The global.secrets.AdminSecret
field sets a secret for Admin API.
It can be configured via global.secrets.AdminSecret
as a plain text or Kubernetes secret which includes AdminSecret
key in it. Then, this secret must be referenced via global.secrets.useSecretName
.
global:
secrets:
useSecretName: "mysecret" # where mysecret includes `AdminSecret` key with the desired value.
Note
Once global.secrets.useSecretName
is declared, it takes precedence over global.secrets.APISecret
and global.secrets.AdminSecret
.
Dashboard License
In order to refer to a Tyk Dashboard license through a Kubernetes secret, please use global.secrets.useSecretName
, where the secret should contain a key called DashLicense
.
MDCB License
In order to refer to a Tyk MDCB license through a Kubernetes secret, please use tyk-mdcb.mdcb.useSecretName
, where the secret should contain a key called MDCBLicense
.
MDCB Secret
In order to set the secret for accessing MDCB secure HTTP endpoints through a Kubernetes secret, please use tyk-mdcb.mdcb.useSecretName
, where the secret should contain a key called securitySecret
.
Tyk Developer Portal License
In order to refer to a Tyk Developer Portal license through a Kubernetes secret, please use tyk-dev-portal.useSecretName
, where the secret should contain a key called DevPortalLicense
.
Tyk Developer Portal Admin Password
In order to refer to a Tyk Developer Portal’s admin password through a Kubernetes secret,
please use global.adminUser.useSecretName
, where the secret should contain a key called adminUserPassword
.
Tyk Developer Portal Storage Connection String
In order to refer to a Tyk Developer Portal connection string to the selected database through a Kubernetes secret, please use tyk-dev-portal.useSecretName
, where the secret should contain a key called DevPortalStorageConnectionString
.
Note
If tyk-dev-portal.useSecretName
is in use, please add all keys mentioned to the secret.
Tyk Developer Portal AWS S3 Access Key ID
In order to refer to a Tyk Developer Portal AWS S3 Access Key ID through a Kubernetes secret, please use tyk-dev-portal.useSecretName
, where the secret should contain a key called DevPortalAwsAccessKeyId
.
Note
If tyk-dev-portal.useSecretName
is in use, please add all keys mentioned to the secret.
Tyk Developer Portal AWS S3 Secret Access Key
In order to refer Tyk Developer Portal connection string to the selected database through Kubernetes secret,
please use tyk-dev-portal.useSecretName
, where the secret should contain a key called
DevPortalAwsSecretAccessKey
.
Note
If tyk-dev-portal.useSecretName
is in use, please add all keys mentioned to the secret.
Redis Password
The Redis password can also be provided via a secret. Store the Redis password in Kubernetes secret and refer to this secret via global.redis.passSecret.name
and global.redis.passSecret.keyName
field, as follows:
global:
redis:
passSecret:
name: "yourSecret"
keyName: "redisPassKey"
MongoDB or Postgres connection strings
Storage connection strings can also be provided via a secret.
For MongoDB, suppose you have a secret named yourSecret
and you have the mongo connection URL stored in key mongoConnectionURLkey
. Store the connection string in Kubernetes secret and refer to this secret via global.mongo.connectionURLSecret.name
and global.mongo.connectionURLSecret.keyName
field, as follows:
- MongoDB:
global:
mongo:
connectionURLSecret:
name: "yourSecret"
keyName: "mongoConnectionURLkey"
For Postgres, suppose you have a secret named yourSecret
and you have the postgres connection string stored in key postgreConnectionURLkey
. Store the connection string in Kubernetes secret and refer to this secret via global.postgres.connectionStringSecret.name
and global.postgres.connectionStringSecret.keyName
field, as follows:
- Postgres:
global:
postgres:
connectionStringSecret:
name: "yourSecret"
keyName: "postgreConnectionURLkey"
Tyk Operator License
It can be configured via global.license.operator
as a plain text or Kubernetes secret which includes OperatorLicense
key in it. Then, this secret must be referenced via global.secrets.useSecretName
.
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.
Gateway Configurations
Note
In Tyk control plane, Tyk Gateway acts as a management gateway that is used for creation of keys and certificates. It does not service API requests. It is important to ensure there is no public access to it and it must not be sharded (tagged) as it “belongs” to the whole Tyk installation.
Configure the following details below, inside the tyk-gateway
section.
Update Tyk Gateway Version
Set version of gateway at tyk-gateway.gateway.image.tag
. You can find the list of version tags available from Docker hub. Please check Tyk Release notes carefully while upgrading or downgrading.
Enabling TLS
Enable TLS
We have provided an easy way to enable TLS via the global.tls.gateway
flag. Setting this value to true will automatically enable TLS using the certificate provided under tyk-gateway/certs/.
Configure TLS secret
If you want to use your own key/cert pair, please perform the following steps:
- Create a TLS secret using your cert and key pair.
- Set
global.tls.gateway
to true. - Set
tyk-gateway.gateway.tls.useDefaultTykCertificate
to false. - Set
tyk-gateway.gateway.tls.secretName
to the name of the newly created secret.
Add Custom Certificates
To add your custom Certificate Authority(CA) to your containers, you can mount your CA certificate directly into /etc/ssl/certs folder.
extraVolumes:
- name: self-signed-ca
secret:
secretName: self-signed-ca-secret
extraVolumeMounts:
- name: self-signed-ca
mountPath: "/etc/ssl/certs/myCA.pem"
subPath: myCA.pem
Enabling gateway autoscaling
You can enable autoscaling of the gateway by --set tyk-gateway.gateway.autoscaling.enabled=true
. By default, it will enable the Horizontal Pod Autoscaler
resource with target average CPU utilization at 60%, scaling between 1 and 3 instances. To customize those values you can modify the tyk-gateway
section of values.yaml
as shown below:
tyk-gateway:
gateway:
autoscaling:
enabled: true
minReplicas: 3
maxReplicas: 30
Built-in rules include tyk-gateway.gateway.autoscaling.averageCpuUtilization
for CPU utilization (set by default at 60%) and tyk-gateway.gateway.autoscaling.averageMemoryUtilization
for memory (disabled by default). In addition to that you can define rules for custom metrics using tyk-gateway.gateway.autoscaling.autoscalingTemplate
list:
tyk-gateway:
gateway:
autoscaling:
autoscalingTemplate:
- type: Pods
pods:
metric:
name: nginx_ingress_controller_nginx_process_requests_total
target:
type: AverageValue
averageValue: 10000m
Pump Configurations
To enable Pump, set global.components.pump
to true and configure the following parameters included below inside the tyk-pump
section.
Pump | Configuration |
---|---|
Prometheus Pump (Default) | Add the value prometheus to the tyk-pump.pump.backend entry and add connection details for Prometheus under tyk-pump.pump.prometheusPump . |
Mongo Pump | Add mongo to tyk-pump.pump.backend and add connection details for mongo under global.mongo . |
Mongo Selective Pump | Add mongo-selective to tyk-pump.pump.backend and add connection details for mongo under global.mongo . |
Mongo Aggregate Pump | Add mongo-aggregate to tyk-pump.pump.backend and add connection details for mongo under global.mongo . |
Postgres Pump | Add postgres to tyk-pump.pump.backend and add connection details for postgres under global.postgres . |
Postgres Aggregate Pump | Add postgres-aggregate to tyk-pump.pump.backend and add connection details for postgres under global.postgres . |
Uptime Pump | Set tyk-pump.pump.uptimePumpBackend to mongo or postgres or "" |
Other Pumps | Add the required environment variables in tyk-pump.pump.extraEnvs |
Note
For additional information on Tyk Pump configurations, refer to the Setup Dashboard Analytics documentation.
To explore the list of supported backends for Tyk Pump, please visit Pump Backends.
Prometheus Pump
Add prometheus
to tyk-pump.pump.backend
and add connection details for Prometheus under tyk-pump.pump.prometheusPump
.
We also support monitoring using Prometheus Operator. All you have to do is set tyk-pump.pump.prometheusPump.prometheusOperator.enabled
to true.
This will create a PodMonitor resource for your Pump instance.
# prometheusPump configures Tyk Pump to expose Prometheus metrics.
# Please add "prometheus" to .Values.pump.backend in order to enable Prometheus Pump.
prometheusPump:
# host represents the host without port, where Tyk Pump serve the metrics for Prometheus.
host: ""
# port represents the port where Tyk Pump serve the metrics for Prometheus.
port: 9090
# path represents the path to the Prometheus collection. For example /metrics.
path: /metrics
# customMetrics allows defining custom Prometheus metrics for Tyk Pump.
# It accepts a string that represents a JSON object. For instance,
#
# customMetrics: '[{"name":"tyk_http_requests_total","description":"Total of API requests","metric_type":"counter","labels":["response_code","api_name","method","api_key","alias","path"]}, { "name":"tyk_http_latency", "description":"Latency of API requests", "metric_type":"histogram", "labels":["type","response_code","api_name","method","api_key","alias","path"] }]'
customMetrics: ""
# If you are using prometheus Operator, set the fields in the section below.
prometheusOperator:
# enabled determines whether the Prometheus Operator is in use or not. By default,
# it is disabled.
# Tyk Pump can be monitored with PodMonitor Custom Resource of Prometheus Operator.
# If enabled, PodMonitor resource is created based on .Values.pump.prometheusPump.prometheusOperator.podMonitorSelector
# for Tyk Pump.
enabled: false
# podMonitorSelector represents a podMonitorSelector of your Prometheus resource. So that
# your Prometheus resource can select PodMonitor objects based on selector defined here.
# Please set this field to the podMonitorSelector field of your monitoring.coreos.com/v1
# Prometheus resource's spec.
#
# You can check the podMonitorSelector via:
# kubectl describe prometheuses.monitoring.coreos.com <PROMETHEUS_POD>
podMonitorSelector:
release: prometheus-stack
Mongo pump
To enable Mongo pump, add mongo
to tyk-pump.pump.backend
and add connection details for mongo under global.mongo
. See Mongo Installation section above.
By default, it will enable Mongo Aggregate, Mongo Graph Pump and Mongo Selective Pump.
SQL Pump
To enable SQL pump, add postgres
to tyk-pump.pump.backend
and add connection details for postgres under global.postgres
. See PostgresSQL Installation section above.
By default, it will enable Postgres Aggregate, Postgres Graph Aggregate, SQL Pump and SQL graph pump.
Uptime Pump
Uptime Pump can be configured by setting pump.uptimePumpBackend
in values.yaml file. It supports the following values:
- mongo: Used to set mongo pump for uptime analytics. Mongo Pump should be enabled.
- postgres: Used to set postgres pump for uptime analytics. Postgres Pump should be enabled.
- empty: Used to disable uptime analytics.
# uptimePumpBackend configures uptime Tyk Pump. ["", "mongo", "postgres"].
# Set it to "" for disabling uptime Tyk Pump. By default, uptime pump is disabled.
uptimePumpBackend: ""
Other Pumps
To setup other backends for pump, refer to this document and add the required environment variables in pump.extraEnvs
Tyk Dashboard Configurations
Tyk Dashboard License (Required)
Tyk Dashboard License is required. It can be set up in global.license.dashboard
or through secret global.secrets.useSecretName
. The secret should contain a key called DashLicense.
global:
license:
# The license key needed by Tyk Dashboard to work.
#
# NOTE: If you do not want to store license as a plain text in the file, you can use a Kubernetes secret
# that stores the dashboard license. Please see `.global.secrets.useSecretName`.
dashboard: ""
Enabling Dashboard TLS
Assuming that TLS certificates for the Tyk Dashboard are available in the Kubernetes Secret tyk-dashboard-tls
, follow these steps to enable TLS:
- Set
global.tls.dashboard
totrue
. - Set
tyk-dashboard.dashboard.tls.secretName
to the name of the Kubernetes secret containing TLS certificates for the Tyk Dashboard, in this case,tyk-dashboard-tls
. - Define certificate configurations in
tyk-dashboard.dashboard.tls.certificates
, which generatesTYK_DB_HTTPSERVEROPTIONS_CERTIFICATES
for the Tyk Dashboard.
Optional Steps, if needed:
- Modify the secret mount path on the Tyk Dashboard Pod via
tyk-dashboard.dashboard.tls.certificatesMountPath
. - If necessary, either enable
insecureSkipVerify
viatyk-dashboard.dashboard.tls.certificates
, or mount CA information throughtyk-dashboard.dashboard.extraVolumes
andtyk-dashboard.dashboard.extraVolumeMounts
. - If the
tyk-bootstrap
chart is used to bootstrap the Tyk Dashboard, ensure that bootstrap app can validate certificate of Tyk Dashboard or enableinsecureSkipVerify
in thetyk-bootstrap
chart. - If the Tyk Gateway connects to the Tyk Dashboard, confirm that the Tyk Gateway has appropriate certificates for connecting to the Tyk Dashboard
Audit Log Configurations
You can manage audit logging for Tyk Dashboard via auditLogs
:
auditLogs.enabled
: Enables or disables audit logging. It sets corresponding Dashboard environment variableTYK_DB_AUDIT_ENABLED
. Disabled by default.auditLogs.type
: Specifies the storage type for audit logs (db
orfile
). It sets corresponding Dashboard environment variableTYK_DB_AUDIT_STORETYPE
. Set tofile
by default.auditLogs.format
: Defines the format of audit log files (json
ortext
). It sets corresponding Dashboard environment variableTYK_DB_AUDIT_FORMAT
. Set totext
by default.auditLogs.path
: Sets the path to the audit log file. It sets corresponding Dashboard environment variableTYK_DB_AUDIT_PATH
. Set to "" by default.auditLogs.enableDetailedRecording
: Enables detailed logging, including HTTP requests (headers only) and full HTTP responses. It sets corresponding Dashboard environment variableTYK_DB_AUDIT_DETAILEDRECORDING
. Disabled by default.
OPA Configurations
You can manage OPA (Open Agent Policy) for Tyk Dashboard via opa
:
opa.enabled
: Enables OPA support. It sets corresponding Dashboard environmentTYK_DB_SECURITY_OPENPOLICY_ENABLED
. Disabled by default.opa.debug
: Activates OPA debug mode for detailed logging of policy execution. It sets corresponding Dashboard environmentTYK_DB_SECURITY_OPENPOLICY_DEBUG
. Disabled by default.opa.api
: Enables OPA API mode to manage policies via the Dashboard API. It sets corresponding Dashboard environmentTYK_DB_SECURITY_OPENPOLICY_ENABLEAPI
. Disabled by default.opa.allowAdminPasswordReset
: Required if OPA is enabled with its default policies. It sets corresponding Dashboard environmentTYK_DB_SECURITY_ALLOWADMINRESETPASSWORD
. Enabled by default.
Tyk MDCB Configurations
Tyk MDCB License (Required)
Tyk MDCB requires a license to be set at tyk-mdcb.mdcb.license
. This field is mandatory and must be configured.
To enhance security and avoid storing plaintext values for the MDCB license directly in the Helm value file, an alternative approach is available. You can store the license in a Kubernetes Secret and reference it externally.
Set the license in the Kubernetes Secret and provide the secret’s name through tyk-mdcb.mdcb.useSecretName
. The Secret must contain a key named MDCBLicense
.
Tyk MDCB Listen Port
The tyk-mdcb.mdcb.listenPort
field represents a RPC port which worker Tyk Gateways will connect to.
Setting tyk-mdcb.mdcb.listenPort
field opens a port on MDCB container and MDCB service targets this port.
It is used to set TYK_MDCB_LISTENPORT
Tyk MDCB HTTP Port
The HTTP port for Tyk MDCB is configurable via the tyk-mdcb.mdcb.httpPort
field.
This port enables MDCB to accept standard HTTP requests, such as health checks.
It also defines the path for liveness and readiness probes.
It is used to set TYK_MDCB_HTTPPORT
in MDCB 2.6.0+ or TYK_MDCB_HEALTHCHECKPORT
in MDCB 2.5.x or prior.
Enabling secured HTTP endpoints
The MDCB OAS API has secured HTTP endpoints, like /dataplanes
which return list of gateway nodes connected. By default, this endpoint is disabled to avoid unintended leakage of data plane information. To enable this endpoint, set tyk-mdcb.mdcb.security.enableHttpSecureEndpoints
to true
. It is used to set TYK_MDCB_SECURITY_ENABLEHTTPSECUREENDPOINTS
. Also, you need to set a secret that can be used to access this endpoint via tyk-mdcb.mdcb.security.secret
field.
Enabling MDCB TLS
Assuming that TLS certificates for the Tyk MDCB are available in the Kubernetes Secret mdcb-tls-secret
, follow these steps to enable TLS for RPC connection:
- Set
tyk-mdcb.mdcb.tls.useSSL
to true. - Set
tyk-mdcb.mdcb.tls.secretName
to the name of the Kubernetes secret containing TLS certificates for the Tyk MDCB, in this case,mdcb-tls-secret
.
tyk-mdcb:
mdcb:
tls:
# enables ssl for mdcb
useSSL: true
# the path to where the keys will be mounted in the pod
certificatesMountPath: "/etc/certs"
# location to pem encoded private key
certificateKeyFile: "/etc/certs/tls.key"
# location to pem encoded certificate
certificateCertFile: "/etc/certs/tls.crt"
# the name of the secret
secretName: "mdcb-tls-secret"
# the name of the volume
volumeName: "mdcb-tls-secret-volume"
To enable TLS for MDCB HTTP connection, use tyk-mdcb.mdcb.httpServerOptions
. The configuration includes settings such as useSSL
, certificateKeyFile
, certificateCertFile
and minVersion
. For other HTTP server options, users can utilize extraEnvs to configure additional parameters.
tyk-mdcb:
mdcb:
# defines the SSL/TLS settings for the http server where the healthcheck is exposed
httpServerOptions:
# if enabled then the endpoints will be served over https
useSSL: true
certificateKeyFile: /path-to-cert-keyfile
certificateCertFile: /path-to-certfile
# For TLS 1.0 use 769, for TLS 1.1 use 770, for TLS 1.2 use 771, for TLS 1.3 use 772
minVersion: 771
Tyk Bootstrap Configurations
To enable bootstrapping, set global.components.bootstrap
to true
. It would run tyk-k8s-bootstrap to bootstrap tyk-control-plane
and to create Kubernetes secrets that can be utilized in Tyk Operator and Tyk Developer Portal.
Note
During bootstrapping, admin user needs to reset its password. It may be denied by Dashboard OPA rules if OPA was enabled. Please disable OPA during the initial bootstrapping or set Dashboard configuration TYK_DB_SECURITY_ALLOWADMINRESETPASSWORD to true.
Bootstrapped Environments
If Tyk is already bootstrapped, the application will bypass the creation of the Tyk Organization and Admin User, proceeding directly with the creation of Kubernetes Secrets.
Given that the Kubernetes Secrets require values for TYK_AUTH
and TYK_ORG
, it is essential to provide these values through the respective environment variables, called TYK_K8SBOOTSTRAP_TYK_ADMIN_AUTH
for TYK_AUTH
and TYK_K8SBOOTSTRAP_TYK_ORG_ID
for TYK_ORG
.
Ensure that these environment variables are set appropriately to postInstall
hook for bootstrapped environments.
Tyk Developer Portal Configurations
To enable Tyk Developer Portal, set global.components.devPortal
to true, and configure below inside tyk-dev-portal
section.
Tyk Developer Portal License (Required)
Tyk Developer Portal License is required. It can be set up in tyk-dev-portal.license
or through secret global.secrets.useSecretName
. The secret should contain a key called DevPortalLicense
.
tyk-dev-portal:
# Tyk Developer Portal license.
license: ""
Tyk Developer Portal Database
Note
Tyk no longer supports SQLite as of Tyk 5.7.0. To avoid disruption, please transition to PostgreSQL, MongoDB, or one of the listed compatible alternatives.
By default, Tyk Developer Portal use sqlite3
to store portal metadata. If you want to use a different SQL Database, please modify the section below.
tyk-dev-portal:
database:
# This selects the SQL dialect to be used
# The supported values are mysql, postgres and sqlite3
dialect: "sqlite3"
connectionString: "db/portal.db"
enableLogs: false
maxRetries: 3
retryDelay: 5000
Storage Settings
Tyk Developer Portal supports different storage options for storing the portal’s CMS assets such as images, theme files and Open API Specification files. Please see the Developer Portal Storage settings page for all the available options.
If you use the file system as storage, please set tyk-dev-portal.storage.type
to fs
, and configure tyk-dev-portal.storage.persistence
to mount an existing persistent volume to Tyk Developer Portal.
If you use AWS S3 as storage, please set tyk-dev-portal.storage.type
to s3
, and configure tyk-dev-portal.storage.s3
section with credentials to access AWS S3 bucket.
If you use database as storage, please set tyk-dev-portal.storage.type
to db
, and configure tyk-dev-portal.database
section with database connection details.
tyk-dev-portal:
# Sensitive configuration of Portal could be set using k8s secret
# You can set following fields:
# - DevPortalLicense - Sets LicenseKey for Developer Portal
# - DevPortalStorageConnectionString - Sets connectionString for Developer Portal
# - DevPortalAwsAccessKeyId - Sets AWS S3 Access Key ID
# - DevPortalAwsSecretAccessKey - Sets AWS S3 Secret Access Key
useSecretName: ""
# The hostname to bind the Developer Portal to.
hostName: tyk-dev-portal.org
# Developer Portal license.
license: ""
# Developer portal can be deployed as StatefulSet or as Deployment
kind: StatefulSet
storage:
# User can set the storage type for portal.
# Supported types: fs, s3, db
type: "db"
# Configuration values for using s3 as storage for Tyk Developer Portal
# In case you want to provide the key ID and access key via secrets please
# refer to the existing secret inside the helm chart or the
# .Values.useSecretName field
s3:
awsAccessKeyid: your-access-key
awsSecretAccessKey: your-secret-key
region: sa-east-1
endpoint: https://s3.sa-east-1.amazonaws.com
bucket: your-portal-bucket
acl: private
presign_urls: true
persistence:
mountExistingPVC: ""
storageClass: ""
accessModes:
- ReadWriteOnce
size: 8Gi
annotations: {}
labels: {}
selector: {}
database:
# This selects the SQL dialect to be used
# The supported values are mysql, postgres and sqlite3
dialect: "sqlite3"
connectionString: "db/portal.db"
enableLogs: false
maxRetries: 3
retryDelay: 5000
Other Configurations
Other Developer Portal configurations can be set by using environment variables with extraEnvs
fields, e.g.:
tyk-dev-portal:
extraEnvs:
- name: PORTAL_LOG_LEVEL
value: debug
Tyk Operator Configurations
Tyk Operator is a licensed component that requires a valid key for operation. Please refer to the Tyk Operator Installation Guide for detailed information on the installation and upgrade processes.
Prior to installing Tyk Operator, ensure that a valid license key is provided by setting global.license.operator
field in values.yaml file. You can set license key via a Kubernetes secret using global.secrets.useSecretName
field. The secret should contain a key called OperatorLicense
.
In order to enable installing Tyk Operator along-side Tyk Control Plane installation, please set global.components.operator
to true
.
All other configurations related to Tyk Operator are available under tyk-operator
section of values.yaml
file.
Tyk Operator needs a cert-manager to be installed. Ensure that cert-manager is installed as described in the official documentation: Installing Tyk Operator.