See what makes Kong the fastest, most-adopted API gateway
Check out the latest Kong feature releases and updates
Single platform for SaaS end-to-end connectivity
Enterprise service mesh based on Kuma and Envoy
Collaborative API design platform
How to Scale High-Performance APIs and Microservices
Call for speakers & sponsors, Kong API Summit 2023!
5 MIN READ
In this post, we’ll talk about what API SecOps is, including the fundamentals of it and the personas involved. Then, we’ll discuss how API, microservice, and policy lifecycles integrate to produce a secure service in production, and why collaboration and API-First Design are essential for APISecOps success.
API security is a subject that’s top of mind for many from builders up to the C-level — or it should be. Gartner reported API data breaches would be the most common attack vector in 2022, and the number of attacks is predicted to double by 2024.
Combine these API security concerns with the fact that organizations are steering toward multi-platform, hybrid cloud, and even multi-cloud solutions (see: CNCF 2021 Annual Report) and it’s enough to make you wonder: how can we manage the sprawl of APIs in a secure and operationally efficient manner?
Essentially, we need an API management strategy that allows development, governance, and operations teams to work collaboratively to deliver business, security, and operational requirements together.
Because at the end of the day, a business needs the following:
In other words, we need to shift towards an APISecOps practice.
APISecOps is short for API design, security, and operations. The solution centers around the four core fundamentals:
The diagram below provides the 10,000-foot view of an APISecOps solution.
The approach begins with API Design-First where the developer builds the API spec in Insomnia, Kong’s API design and testing suite, using OpenAPI Spec (OAS) best practices and security standards defined by the business.
When the API spec is ready, it will be passed to an automated governance process driven by Kong’s Inso CLI tooling. The Inso CLI is designed for API pipeline automation; it will lint the API spec and translate the spec directly to the Kong Declarative manifest (i.e., the decK manifest).
Once governance tests have been completed, and with the decK manifest in hand, the manifest will be automatically synced to Kong Konnect, the centralized API management platform, performed by Kong’s decK CLI tool. The decK CLI is similarly designed for API pipeline automation and is used to manage Kong Konnect and Kong Gateway configuration declaratively.
The depiction above focuses on the end-to-end delivery of an API. It’s easy to visualize how the three personas (Developers, Governance, and Operators) collaborate, and how the process aligns with the four fundamentals of APISecOps.
But in retrospect, every API has a corresponding microservice and policies. And all the lifecycles (API, Microservice, and Policy) need to work synchronously to deliver a secured service to production.
Let’s dive a bit deeper into this topic to understand how and why these three lifecycles need to be integrated.
If we were to envision how the APISecOps, DevOps, and even PolicyOps lifecycles integrate, it would look something like the diagram below.
What’s important to understand is that policies themselves need to have a lifecycle to build, test, and be approved by the governance leaders.
The PolicyOps lifecycle is critical because, as you can imagine, untested or unreviewed changes could harm the final product. Therefore, the governance team has a lifecycle to put policies into action and are incorporated into the APISecOps lifecycle when ready.
Here, we’ve expanded the view of APISecOps to include multiple stages of testing.
Let’s dive more into the “Mocking” testing phase that is specifically highlighted. This is a great idea because we’re giving stakeholders the opportunity to test, live, that the API behaves as expected from business, security, and operational angles. It provides confidence to move forward. It also increases productivity because the developers aren’t wasting time building code that could be tossed out.
DevOps begins when all stakeholders have confidence in the plan, which they’ve been able to see through the initial stages of APISecOps.
The development team is now going to build out the backend code. The code promotion scheme aligns with the approved API spec until finally the service as a whole, both the API spec and supporting code, are released to production.
What exactly is the takeaway from all of this? (No, the first takeaway isn’t that our engineering organization has work to do.) It’s that collaboration and API design-first are keys to success in APISecOps.
Teamwork, collaboration, whatever you want to call it — it’s the first key to success. Because at the end of the day, Developers, Governance, and Operators all matter. Poor policies mean an insecure API. A poorly documented API spec means a lack of security. And poorly developed backend code follows suit: insecurity.
The second takeaway is that the process begins with API Design-First.
Shifting toward an API Design-First approach may feel like an impediment at first. But from this vantage point, all teams can answer the questions that they value most:
In summary, in an APISecOps strategy, API Design-First is breaking down the barriers of communication and improving the productivity of the business as a whole.
We’ve covered how to integrate Governance, API Design-First, and GitOps into an APISecOps strategy. But how do we now deliver this when APIs are rapidly becoming scattered across multi-platform, hybrid cloud ecosystems? Check out this APISecOps tutorial as we discuss Centralization in the APISecOps Hybrid Cloud solution and how a Kong / Red Hat Openshift strategy comes into play.
Interested in getting a practical demo of APISecOps with Kong Konnect and ROSA? Check out the tutorial in the Kong APISecOps repository on GitHub.
Learn how to make your API strategy a competitive advantage.