Table of Contents
An important part of setting up a new IAM cluster is choosing the right architectural pattern that fits your needs and integrates with your existing infrastructure. Here are a few that we commonly see and recommend. IAM itself is greatly flexible, and can be setup in many ways. We present these as starting points in hopes that you find that using or extending one of these patterns provides an ideal fit for your unique needs.
IAM between Client and Upstream
The classic architectural pattern we see customers setting up is adding IAM in between some, or all, of their API traffic. IAM is installed in your prefered hosting provider, and configured to proxy traffic to the existing APIs. Note that in this pattern the APIs are still accessible directly, that is both through the proxy and also without being routed through the API Gateway. We see this during initial testing, and migration phases, before customers eventually route all traffic through IAM.
The pros of this approach are that it is simple to setup and configure. All it requires is setup, and coordinating new traffic to use the gateway. Older traffic will still flow directly to the APIs.
The cons are, in this case, the same as the pros. It's a simple pattern, which works for new traffic, but older traffic will continue to be routed directly to the API and not take advantage of rate limiting, auth, or other plugins configured on the IAM gateway.
Often we see this initial IAM configuration morph into one where the APIs are walled off behind a firewall, which we will visit in the next pattern.
IAM and APIs behind Firewall
The next pattern we see, and the next step for security, is to setup API servers behind a firewall and only allow the IAM API Gateway be accessible to the public.
This is a popular architecture pattern that we see with customers who have publicly available APIs. Either they are migrating from the initial pattern, improving security by cordoning off direct access to the APIs, or choosing it for their general use.
This architecture pattern is the one we recommend for most customers. It is straightforward to setup, and offers security and control over API access.
The IAM cluster would be placed behind a firewall, or within an Amazon VPC. The IAM cluster's port 80 or 443, which ever your public API is available on, would be opened to the outside world. Inside the firewall the API servers would only allow connections from the IAM cluster. Other IP:ports may need to be opened for the API servers to reach resources they need to fulfill any requests.
Access to the IAM Admin API can be secured in a couple of different ways. Depending on your needs you would lock it down to localhost on the machine it is running on, use the firewall to prevent access from anyone outside your network, or proxy the Admin API through IAM itself, and secure it using one of the authentication plugins.
With IAM you also have the option of using Role Based Access Control (RBAC) to shape fine grained access for your team, and co-workers. RBAC in IAM is used to create roles with defined permissions; roles are then assigned to users who are limited in what they can and cannot do by the permissions. Roles could be created for read-only roles; for when you want to let co-workers look, but not edit, the configuration. You could also create roles for different teams; giving them access to edit and update only their APIs.
Separate IAM Admin Node
For security conscious customers we recommend a pattern of having a single node in an IAM cluster allow access to the Admin API.
Each node in IAM cluster can be configured using its kong.conf file. Two separate configurations can be created, one for a proxy only node, and the other for an admin only node. The proxy only nodes would be accessible from the outside world. They would connect to the database and the upstream APIs that are behind the firewall. The admin only node would be inside the firewall, or a separate firewall (or VPC on AWS), and it would connect to the database that the proxy nodes connects to.
So long as the proxy nodes and admin nodes use the same database they will be part of the same cluster. The admin node itself can be located anywhere. There are a few different ways to achieve this. Read securing the IAM Admin API for details.
IAM as a tool is flexible, and offers many possibilities for incorporating it into your existing infrastructure. These patterns we touch upon are the ones we commonly see and recommend. Every situation is unique, and we are happy to assist you with your specific needs.