Managing Multiple Organizations with Tyk Operator CRDs

This guide explains how to efficiently manage multiple organizations within Tyk using Tyk Operator Custom Resource Definitions (CRDs).

Please consult the key concepts for Tyk Operator documentation for an overview of the fundamental concepts of organizations in Tyk and the use of OperatorContext to manage resources for different teams effectively.

The guide includes practical examples and best practices for multi-tenant API management. Key topics include defining OperatorContext for connecting and authenticating with a Tyk Dashboard, and using contextRef in API Definition objects to ensure configurations are applied within specific organizations. The provided YAML examples illustrate how to set up these configurations.

Defining OperatorContext

An OperatorContext specifies the parameters for connecting and authenticating with a Tyk Dashboard. Below is an example of how to define an OperatorContext:

apiVersion: tyk.tyk.io/v1alpha1
kind: OperatorContext
metadata:
  name: team-alpha
  namespace: default
spec:
  env:
    # The mode of the admin api
    # ce - community edition (open source gateway)
    # pro - dashboard (requires a license)
    mode: pro
    # Org ID to use
    org: *YOUR_ORGANIZATION_ID*
    # The authorization token this will be set in x-tyk-authorization header on the
    # client while talking to the admin api
    auth: *YOUR_API_ACCESS_KEY*
    # The url to the Tyk Dashboard API
    url: http://dashboard.tyk.svc.cluster.local:3000
    # Set this to true if you want to skip tls certificate and host name verification
    # this should only be used in testing
    insecureSkipVerify: true
    # For ingress the operator creates and manages ApiDefinition resources, use this to configure
    # which ports the ApiDefinition resources managed by the ingress controller binds to.
    # Use this to override default ingress http and https port
    ingress:
      httpPort: 8000
      httpsPort: 8443

For better security, you can also replace sensitive data with values contained within a referenced secret with .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.

apiVersion: tyk.tyk.io/v1alpha1
kind: OperatorContext
metadata:
  name: team-alpha
  namespace: default
spec:
  secretRef:
    name: tyk-operator-conf ## Secret containing keys TYK_AUTH and TYK_ORG
    namespace: alpha
  env:
    mode: pro
    url: http://tyk.tykce-control-plane.svc.cluster.local:8001
    insecureSkipVerify: true
    ingress:
      httpPort: 8000
      httpsPort: 8443
    user_owners:
    - a1b2c3d4f5e6f7
    user_group_owners:
    - 1a2b3c4d5f6e7f

You can provide the following fields through secret as referenced by 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.

Using contextRef in API Definitions

Once an OperatorContext is defined, you can reference it in your API Definition objects using contextRef. Below is an example:

apiVersion: tyk.tyk.io/v1alpha1
kind: ApiDefinition
metadata:
  name: httpbin
  namespace: alpha
spec:
  contextRef:
    name: team-alpha
    namespace: default
  name: httpbin
  use_keyless: true
  protocol: http
  active: true
  proxy:
    target_url: http://httpbin.org
    listen_path: /httpbin
    strip_listen_path: true

In this example, the ApiDefinition object references the team-alpha context, ensuring that the configuration is applied within the alpha organization.