Platform engineering is focused on reducing the friction for software developers. The net result is that platform engineers offer a repeatable, scalable approach to software development and delivery. This is accomplished through the use of cloud provider APIs to provision infrastructure. Platform engineers are sometimes required to build their APIs to orchestrate workflows. At the same time, many organisations are delivering API platforms that turn business processes into digital assets that can be consumed and reused to optimise internal operations and deliver external market solutions. Developer portals and API catalogues track the inventory of the many APIs used by platform engineers and software developers. This multi-pronged approach to consuming and providing APIs requires a thoughtful approach to protecting and managing the many APIs across the organisation. If these APIs go unmanaged, they will become another surface area for malicious use.
Reading list
Learn more about Platform teams and how an API gateway can help.
What is an API Gateway?
An API gateway sits between an API client and a set of backend services. It is an API management service that provides a unified entry point for API calls. It acts as a powerful reverse proxy, ensuring all incoming traffic is managed according to configured rules. An API gateway handles the following responsibilities:
- Authentication and authorisation
- Protocol mediation and transformations
- Custom plugins and functions
- Analytics and tracing
- Versioning and lifecycle management
- Caching
- Endpoint protection
- Logging
To learn more about API gateways and their benefits, refer to our article, Reading list What is an API gateway?
Reading list
Read our article, What is an API gateway, to learn more about their benefits.
The need for an API gateway to support platform engineering
One aspect of platform engineering that is sometimes missed is the heavy dependence upon APIs to automate and provide self-service software delivery capabilities. If these APIs are left unprotected, they can expose vulnerabilities that can be costly to the organisation. A recent IBM report indicates that the average cost of a data breach is $4.35M globally and as much as $9.44M for organisations in the United States. This amount increases to $10.10M for the healthcare industry. The report also notes that nearly half of all breaches occur within the cloud, both private ($4.24M) and public ($5.02M). Part of the role of platform engineers is to identify vulnerable areas and ensure they are adequately protected, so they need an API gateway to protect the organisation’s API surface area. It’s an indispensable tool for platform engineers in maintaining a robust and effective software ecosystem.
Reading list
Check out IBM’s report about the cost of data breaches here.
Using an API gateway to protect platform APIs
Platform APIs make up the majority of APIs produced by organisations. They include:
- Infrastructure and automation APIs built and used by platform engineering teams to support the day-to-day needs of developer automation and infrastructure needs.
- Domain APIs that support business operations across the various domain areas of the organisation.
- Experience APIs that support web and mobile applications, often communicating with domain APIs to orchestrate complex workflows.
- Connector APIs that interact with legacy systems adapt legacy data into formats that domain APIs need.
These APIs are inventoried and available for self-service developer onboarding using an API catalogue and internal developer portal. An API gateway is designed to protect these types of APIs from unauthorised access. While some domain APIs may be available for use by any developer in the organisation, others may have more restrictive access due to the sensitive data and processes they offer. Likewise, experience APIs should restrict their access to only the web and mobile applications using them. Without an API gateway, anyone could interact with any API at any time and gain access to sensitive data and processes. Platform engineers must recognise the importance of an API gateway as part of the shared infrastructure of their organisation.
Using an API gateway to protect public APIs
Public APIs are those used directly by customers and partners to automate their workflows and integrate with internal systems. Unlike platform APIs that are mostly limited to network traffic internal to the organisation, public APIs are externalised for general access to the internet. As such, they require configuration rules to restrict their access to only authorised parties. API tokens or API keys are used to identify the API client as a customer or partner, limiting API access to only official operations and tracking their usage for reporting purposes. In some cases, public APIs may enforce request limits for customers and partners. Rate limiting is a feature of an API gateway that prevents the overuse of an API by enforcing a strict number of requests over a specific period. Measuring the number of API requests per second, per minute, or hour is most common. If the rate is exceeded, incoming API requests are denied until the period has been exceeded and the rate limits are reset. Rate limiting is helpful to control infrastructure spend and prevent customers and partners from abusing an API.
Using an API gateway to protect third-party APIs
Platform engineers will use a variety of third-party APIs in their day-to- day work. This may include SaaS-based solutions that offer APIs for automation, cloud infrastructure APIs for provisioning and monitoring cloud-based resources, and business partners that support day-to-day operations via API integration. API gateways can proxy outbound requests to third-party APIs, just like they protect internal APIs from incoming requests. However, the API gateway can track external API usage and report on the applications using each third-party API. It can also hide sensitive data and third-party API keys or tokens, instead offering a secondary API token to applications consuming third-party APIs. Using an API gateway between applications and third-party APIs limits the organisation’s exposure by preventing the need to share third-party API tokens with delivery teams. Should the third-party API token be leaked accidentally by a developer, the entire organisation would be forced to expire and generate a new third-party API token. Instead, the API gateway injects the third-party API token on behalf of the application as it proxies the API call to the third-party system. If the secondary token is compromised, only the application must rotate its secondary API token rather than every application using the third-party API. Platform engineers should use the API gateway’s ability to proxy third-party API tokens to improve their organisation’s security posture.
Chapter recap
The multi-pronged approach to consuming and providing APIs requires a thoughtful approach to protecting and managing the many APIs across the organisation.