Tyk Control Plane Chart

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.

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.

Tyk Control Plane Installations

Installing The Chart

To install the chart from Helm repository in namespace tyk with the release name tyk-cp, 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:

1. Set Redis connection details
2. Set Mongo or PostgreSQL connection details
3. Tyk Dashboard License
4. Tyk MDCB License
5. 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-cp 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-cp -n tyk

This removes all the Kubernetes components associated with the chart and deletes the release.

Upgrading Chart

helm upgrade tyk-cp 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:

Key Notes on Bootstrapping:

• Bootstrapping is triggered only during a helm install and does not run during a helm upgrade.
• If global.components.bootstrap is set to false, 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:

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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:

1. Create a TLS secret using your cert and key pair.
2. Set global.tls.gateway to true.
3. Set tyk-gateway.gateway.tls.useDefaultTykCertificate to false.
4. 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.

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:

1. mongo: Used to set mongo pump for uptime analytics. Mongo Pump should be enabled.
2. postgres: Used to set postgres pump for uptime analytics. Postgres Pump should be enabled.
3. 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:

1. Set global.tls.dashboard to true.
2. 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.
3. Define certificate configurations in tyk-dashboard.dashboard.tls.certificates, which generates TYK_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 via tyk-dashboard.dashboard.tls.certificates, or mount CA information through tyk-dashboard.dashboard.extraVolumes and tyk-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 enable insecureSkipVerify in the tyk-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 variable TYK_DB_AUDIT_ENABLED. Disabled by default.
• auditLogs.type: Specifies the storage type for audit logs (db or file). It sets corresponding Dashboard environment variable TYK_DB_AUDIT_STORETYPE. Set to file by default.
• auditLogs.format: Defines the format of audit log files (json or text). It sets corresponding Dashboard environment variable TYK_DB_AUDIT_FORMAT. Set to text by default.
• auditLogs.path: Sets the path to the audit log file. It sets corresponding Dashboard environment variable TYK_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 variable TYK_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 environment TYK_DB_SECURITY_OPENPOLICY_ENABLED. Disabled by default.
• opa.debug: Activates OPA debug mode for detailed logging of policy execution. It sets corresponding Dashboard environment TYK_DB_SECURITY_OPENPOLICY_DEBUG. Disabled by default.
• opa.api: Enables OPA API mode to manage policies via the Dashboard API. It sets corresponding Dashboard environment TYK_DB_SECURITY_OPENPOLICY_ENABLEAPI. Disabled by default.
• opa.allowAdminPasswordReset: Required if OPA is enabled with its default policies. It sets corresponding Dashboard environment TYK_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:

1. Set tyk-mdcb.mdcb.tls.useSSL to true.
2. 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.

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

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.