Skip to main content
Version: 4.8

Kong

SCALE DevOps Pipeline v4.5 introduces Kong, an Ingress Controller based on the Kong Gateway. Increasingly, distributed systems and the rising adoption of microservices create new challenges for managing communications across services. Kong API Gateway provides a fast, scalable and flexible platform for complex modern architectures. To know more about Kong please refer to official site or Kong Academy.

Pre-requsites:

Setting up Ingress Endpoints​

Correctly formatted values.yaml (or respective override values.yaml) is a key pre-requisite to enable Kong within SCALE. Ingress endpoint configuration allows to configure multiple hosts for a microservice if required. Sample file below demostrates configurations of both - user defined myapp.netapp.com, its DR host myapp-dr.netapp.com and a dynamically generated host simultaneously.

ingressEndpoints:
- # Dynamically Generate URL
  internal:
    enabled: true
    mappings:
    - prefix: "/"
      rewrite: "/"
  external:
    enabled: false
    mappings:
    - prefix: "/"
      rewrite: "/"
- host: myapp.netapp.com
  internal:
    enabled: true
    mappings:
    - prefix: "/"
      rewrite: "/"
  external:
    enabled: false
    mappings:
    - prefix: "/"
      rewrite: "/"
- host: myapp-dr.netapp.com
  internal:
    enabled: true
    mappings:
    - prefix: "/"
      rewrite: "/"
  external:
    enabled: false
    mappings:
    - prefix: "/"
      rewrite: "/"

Configuring Ingress class​

To enable Kong set Ingress Class to kong in the values.yaml

ingressClassName: kong
dedicatedWAFpolicy: false

Addition of kong.yaml​

SCALE DevOps Pipeline v4.5 adds a new file kong.yaml to helm template to enable Kong. Refer here

Dedicated WAF policy​

SCALE DevOps Pipeline v4.5 enhances application security by applying default WAF policies. In case application requires any dedicated WAF policy please reach out to Network Security Team.

NOTE: if application is using Axway​

Once services are migrated to Kong APIs registered with Axway need to be republished with new certificates (gw.cloudone.netapp.com). This has to be done by all teams who are sharing their APIs to other Apps through Axway.

DNS Swap from Ambassador to Kong​

If you are using our SCALE DevOps recommended DNS configuration (link), then swiching your DNS records over to Kong is simple and self-service through the Service-Now CloudOne DevOps portal (see KB0008262). You should only perform the DNS swap once all services within that namespace (workspace, hostspace, dataspace) has been deployed with ingressClassName: kong.

If you do an nslookup on your host (e.g. myapp.netapp.com) and see 'prdXXx' within the chain (e.g. ...prd06i.cloudone.netapp.com), then your DNS records are pointing to Ambassador. If you see 'gwXXx' (e.g. ...gw06i.cloudone.netapp.com), then they are pointing to Kong.

TLS Configurations​

If the application requires to add TLS configrations with own SSL certificate and key, data for TLS secret can be added into securefile.

ingressSecrets:
- host: myapp.netapp.com
  internal: true
  external: true
  tls:
    crt: |
      -----BEGIN CERTIFICATE-----
      Thequickbrownfoxjumpsoverthelazydog!Thequickbrownfoxjumpsoverthelazy
      dog!Thequickbrownfoxjumpsoverthelazydog!Thequickbrownfoxjumpsoverthe
      lazydog!Thequickbrownfoxjumpsoverthelazydog!=
      -----END CERTIFICATE-----
    key: |
      -----BEGIN PRIVATE KEY-----
      Thequickbrownfoxjumpsoverthelazydog!Thequickbrownfoxjumpsoverthelazy
      dog!Thequickbrownfoxjumpsoverthelazydog!Thequickbrownfoxjumpsoverthe
      lazydog!Thequickbrownfoxjumpsoverthelazydog!Thequickbrownfoxjumpsove
      rthelazydog!Thequickbrownfoxjumpsoverthelazydog!=
      -----END PRIVATE KEY-----