Install plugins post Kong setup

Kubernetes
1

Kong is installed on our Kubernetes cluster using the manifest files. InitContainer is used for the migrations.
And main container does the deployment of Kong. So far so good.

Now, we would like to enable plugins as part of the manifest files itself. Could you please suggest as how we can achieve this?

2

Would you mind clarifying a couple of items:

  • Are you looking to only manage plugin config/enable? And/or,
  • Add plugins that aren’t natively with a Kong deployment?

If just the first item, we use some basic scripts & curl to manage configuration in what call “bootstrap”. This is separate than plugins we use for API policies. Those are managed through the admin api proxy endpoint. That process is handled in our CI/CD process and leveraged changes triggered from our source code management system.

If both are needed, we build Docker images with the specific luarocks install step and then pass KONG_CUSTOM_PLUGINS (https://docs.konghq.com/0.11.x/configuration/#custom_plugins) env variable in the manifest. The changes are push through a CI/CD process.

1 Like
3

we are trying to implement CI/CD process for the KONG?
Can you please let us know how this is been done? We have something like DEV, QA, LIVE environment. In most of our use cases the downstream URL’s and Consumer credentials varies between all these environment.

4

+1 from my side for the question

I have the same use-case and cant find any valid answer on this one. (or any best practices)

Posted a similar question also: Kong entities change management

5

We use a different sub-domain for our gateway cluster in each env and then use the same policy details (with exceptions like OAuth client/secrets, where they apply).

For the credentials piece, we built a platform services portal that allows people to generate JSON files leveraging some similar principles and approaches as eJSON (GitHub - Shopify/ejson: EJSON is a small library to manage encrypted secrets using asymmetric encryption.). This allows us to publish the full policy in source code. The gateways have the upstream private key. We’re not 100% automated as we’re still executing some local scripts to manage the final deployment. Our API platform team is two people :slight_smile:

The repo setup includes an individual repo for the policy. Design and API code are kept separate. This allows developers to build new images (for their API code) and deploy. The policy repo contains a JSON file for each policy resource type (key-auth, policy, oauth, etc.). There’s a secrets JSON file that has a prefix for the env key (like, prod_, stage_ and dev_ - as a prefix to the key authentication_client_id ). We then use a basic template in the JSON files to interpolate values based on the target (using some conditionals and mapping - if KONG_ENV=PROD then go_get_prod_values … you know, deep machine learning stuff)

1 Like