This presentation explores managing the increasing complexity of secure API connectivity by moving beyond traditional API management tools. It introduces the Common Architecture Language Model (CALM) and emphasizes shifting security left through architectural patterns to enable faster, more secure deployments and bridge the developer-security gap.
Read original on InfoQ ArchitectureInitially, API creation seems simple, but adding authentication, authorization, and cross-trust boundary requirements quickly complicates matters. Traditional API management tools, while useful, introduce operational complexity and can hinder portability. As systems scale, automated deployments become crucial, requiring coordination between API services and management layers to ensure zero downtime and consistency. Furthermore, integrating gateways for security, service discovery, and routing to microservices adds another layer of complexity, moving beyond the capabilities of a single API management solution.
Developer and Security Gaps
The article highlights two significant gaps: the developer-infrastructure gap (too much YAML, lack of support for developers with complex tooling) and the developer-security gap (unfamiliarity with security concepts, lack of appropriate training, and security acting as a gate rather than a guide). Bridging these gaps is central to achieving secure and efficient API development.
To address the challenges, the presentation advocates for embedding secure design approaches into system modeling from the beginning. This involves leveraging tools like C4 architecture models to visualize systems and integrating threat modeling early in the design phase. By shifting security left, developers can proactively answer security questions and build robust systems rather than facing 'no' from security teams late in the development cycle. The Common Architecture Language Model (CALM) is introduced as a framework to facilitate this proactive, 'architecture as code' approach, transforming lengthy review cycles into rapid, automated deployments.
# Example of potential 'Architecture as Code' for API policy
apiVersion: api.example.com/v1
kind: APIPolicy
metadata:
name: secure-conference-api
spec:
apiName: conference-attendees-service
security:
authentication:
method: OAuth2
scopes: [read:attendee, write:attendee]
authorization:
roleBased: true
roles: [admin, registered_user]
rateLimiting:
enabled: true
requestsPerSecond: 100
observability:
loggingLevel: INFO
metricsEnabled: true