 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
While organizations today undertake digital transformation, they are increasingly adopting an API-first approach to designing and executing on these initiatives. This coupled with DevOps practices is an integral aspect of these transformation objectives. APIs provide a clear demarcation to implement these practices, and they are also integral to driving DevOps practices that provide the agility to software releases.
However, this DevOps agility needs ensuring APIs are sanctioned and enforcement is not lagging. With agility, arises the challenge to keep all stakeholders in sync, especially the SecOps team that secures the delivery of these APIs. Keeping up with this DevOps agility needs checking and enforcing the security guardrails dynamically at the same pace.
If attention is not paid, DevOps agility can result in shadow APIs outside the purview of enterprise IT. This opens up an opportunity for API abuse. According to Gartner, API abuse will be the most frequent attack vector by 2022.
As stakeholders collaborate to design, build and deliver APIs, OpenAPI spec is adopted as a system to agree on and develop these APIs. In Service-Oriented Architecture (SOA) for instance, it forms a mechanism to share information between the service provider, the service broker and the service consumer.
While the design of APIs is driven using OpenAPI, client and server implementations can be generated in a language of choice using this specification. The delivery of these APIs often involves an intermediate API gateway to provide access, monitoring, authentication, authorization and transformations.
However, oftentimes, API gateways are configured and run independently of OpenAPI spec. This results in configuration on the API gateway drifting away from what is specified in the specification. This potentially creates shadow APIs which are not in the confines of the API gateway and hence does not enforce any security (or other) policies on the API.
While there are tools to generate a client/server (in a language of choice) from OpenAPI spec, the intermediate API gateway ends up being programmed manually.
What if your OpenAPI Spec can be ingested by your API Gateway? And what if this Gateway can be run either as a standalone, sidecar or kubernetes ingress API Gateway.
With such automation, detecting drifts in API Gateway configuration from the OpenAPI becomes easy. It also simplifies updating the API gateway as a part of CI/CD process along with client/server/spec.
Enroute Universal API Gateway is built on Envoy Proxy and can be programmed using OpenAPI Spec. It can be run either as a Standalone Gateway, at Kubernetes Ingress or as a SideCar to enforce the spec specific to a microservice providing this API.
Programming the Enroute (Envoy Router) API Gateway using the enroutectl tool (that is packaged with the image) takes less than a minute. The tool can be used to keep the API Gateway in sync with OpenAPI Spec.
This mechanism of enforcement provides the necessary guardrails with APIs that ensure that APIs not managed or monitored by the IT department can be brought into the IT umbrella as soon as they are created.
Alternatively, shadow APIs can be discovered by opening a default path and monitoring it for traffic hits. This is a mechanism that unblocks the developer and allows for development velocity while IT can stay on top of new developments.
Additionally, enroutectl can also provide drift detection. As the OpenAPI spec gets updated, the tool can be run to check if the API Gateway is programmed with the latest spec.
Enroute provides a mechanism to create Layer-7 ACLs for your API traffic. Network ACLs are a popular mechanism for access control. Enroute provides the ability to automatically create and enforce API ACLs or framework for monitoring shadow APIs.
Enroute community edition ships with advanced rate-limiting. Protecting the API resource is critical both for internal and external use. Enroute can also enforce different rate limits for authenticated or unauthenticated user. More information about advanced rate limiting on Enroute Universal Gateway can be found in the article — Why Every API Needs a Clock.
Enroute Universal API Gateway provides runtime API conformance assessment and shadow API discovery.
Enroute’s flexibility allows running it in any environment, be it public cloud or private cloud. It also provides an ability to enforce Open API spec for your microservices running inside Kubernetes.
Enroute Universal API Gateway community edition allows organizations to prevent API abuse without any cost. It enforces best practices while answering critical questions if the API is permitted or shadow.
Enforcing OpenAPI spec and eliminating shadow APIs is an underserved need, and is aggravated with adoption of DevOps. It needs a shift left approach to enforcing the Spec.
Enroute Universal API Gateway is an OSS project and also has a community edition that includes premium features like different rate limits for authenticated/unauthenticated users, canary deployments, OpenAPI Spec support and works Standalone or as Kubernetes Ingress.
Feature image via Pixabay.
At this time, The New Stack does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: feedback@thenewstack.io.
