Level Up API Operations: Granular API Access Control Meets GitOps

April 18, 2024

We're thrilled to announce the release of a powerful new security feature for managing APIs with Traefik Hub: granular API access control with operation filters. This feature empowers you to control who can access your APIs and what they can do with them with unprecedented precision.

Modern applications rely heavily on APIs, as evidenced by the Cloudflare 2024 API Security report, which found that APIs comprise over half (57%) of internet traffic. As the building blocks of digital infrastructure, APIs play a pivotal role in organizational success. However, securing these critical resources can be challenging. Traditionally, access control options have been limited to all-or-nothing approaches, leaving organizations vulnerable to security risks and compliance gaps.

With Traefik Hub's new granular API access control, you can finally move beyond this restrictive approach. You now have the fine-grained control you need to secure your APIs at the HTTP method and URI path level, ensuring only authorized users can access specific functionalities within your APIs.

The Growing Challenge of Securing APIs in Modern Applications

The expanding landscape of APIs presents a significant challenge for organizations seeking to maintain robust security measures. According to Cloudflare, nearly 60% of organizations grant "write" access to at least half of their APIs, and the prevalence of shadow and zombie APIs further complicates the picture:

Shadow APIs, essentially unmanaged and unsecured application programming interfaces, pose a severe threat due to their inherent lack of oversight and potential access to sensitive data. Cloudflare’s machine learning algorithms found ~33% more API endpoints vs. what customers self-reported. These rogue APIs can lead to data breaches and expose critical information when compromised.
Zombie APIs were once active but have been deprecated or abandoned. They may already be managed but not used actively. Likely, these APIs are not well secured or left unsecured, so they impose an ever-growing risk of becoming compromised or being used to carry out malicious activities.

Additionally, the rise of generative AI introduces new security concerns. While AI holds great promise, its integration also brings potential vulnerabilities, as both AI models and AI-generated code can be susceptible to attack. Forrester predicts that by 2024, a lack of proper security measures could lead to several high-profile data breaches originating from AI-generated code. However, they also believe that up to 90% of data breaches will include a human element.

Furthermore, APIs used for business to business (B2B) communication, while often perceived as more trustworthy due to their authenticated nature, can make organizations fall into a false sense of security. Because these APIs typically serve a smaller, known set of partners, security teams might underestimate the potential for abuse. However, malicious actors can exploit APIs in unforeseen ways, accessing confidential data and restricted functionalities or compromising previously trusted partners, infiltrating their systems to search for more vulnerable APIs.

Finally, the OWASP Top 10 API Security Risks reveal a worrying trend, with over half of the listed points focusing on API consumption and authentication flaws. These vulnerabilities—such as broken authentication, unrestricted resource consumption, and improper access controls—can be exploited by attackers to gain unauthorized access to sensitive data and functionalities.

Granular API Access Control to the Rescue

Traefik Hub now empowers you to move beyond the limitations of traditional, all-or-nothing API access control. Our new granular API access control feature allows you to precisely define who can access your APIs and what actions they are authorized to perform on a per-endpoint basis. This fine-grained control, achieved through HTTP method and URI path filtering, ensures that only authorized users can access specific functionalities within your APIs, significantly enhancing your overall security posture.

We've taken a modern and efficient approach, leveraging the power of GitOps and Kubernetes Custom Resource Definitions (CRDs). GitOps, a popular methodology for infrastructure automation, allows you to manage your access control rules in Git repositories, ensuring version control, collaboration, and easy rollbacks. CRDs, on the other hand, provide a Kubernetes-native way to define custom resources specific to your needs, such as API access control rules. This combination offers several benefits:

Easy to read and understand: CRDs are written in a human-readable format, making them easier to understand and manage than complex configuration files.
Validation and consistency: CRD validity is enforced through specific schema validation, ensuring the consistency and integrity of your access control rules.
Version control and auditability: Git provides built-in version control capabilities, allowing you to track changes to your access control rules and easily roll back to previous versions if needed. Additionally, Git enables comprehensive auditability of access control policy changes.
Automated policy application: By leveraging Kubernetes-native labels and selectors, Traefik Hub can automatically apply your API access control policies to newly published APIs based on defined criteria, streamlining the security configuration process.

Key Features of Traefik Hub's Uniquely Flexible API Security

The flexibility of Traefik Hub's granular API access control sets its apart from similar solutions. Here are the key features and functionalities that define our unique approach:

Support for all standard HTTP methods: Our solution empowers you to define access control rules for all commonly used HTTP methods, including GET, POST, PUT, DELETE, PATCH, and more. This fine-grained control allows you to grant or deny access based on the specific actions users attempt to perform on your APIs.
Versatile URI path definition: You can define URI paths with various options, including:
- Exact paths: Grant or deny access to specific API endpoints
- Path prefixes: Control access to a group of related endpoints sharing a common prefix
- Regular expressions: Define complex patterns for matching multiple URI paths under a single rule, simplifying access control management.
Powerful rule combinations: Go beyond simple allow/deny rules and leverage AND/OR logic to create sophisticated access control scenarios. This allows you to combine path and method restrictions to define precisely who can access what and under what conditions.
Simplified rule management with operation sets: Introduce reusable sets of path and method combinations, called "operation sets," to streamline rule creation and management. This approach promotes code organization and reduces redundancy, especially when defining access control rules for multiple APIs with similar functionalities.
Granular control at both API and API version levels: Enforce access control not only at the API level but also at the individual API version level. This enables you to adapt access policies based on specific functionalities or security requirements introduced in different API versions.

Business Benefits: Efficiently Elevate Your API Security

By utilizing Traefik Hub’s novel operation filtering, you can unlock a plethora of benefits for your organization:

Craft highly customized rules tailored to your specific API security needs with streamlined access control policy management leveraging GitOps and CRDs for efficient access control rule creation, version control, and auditability.
Mitigate security risks and limit data exposure by granting access only to authorized users and actions on your APIs. Implement zero trust principles by restricting API access based on specific needs, minimizing the potential for data breaches and unauthorized exposure.
Improve developer experience by enabling them to easily understand and manage access control policies, thanks to clear and concise rules.
Facilitate adherence to industry regulations and compliance requirements. Many industries have regulations governing data access and security. Granular access control simplifies compliance by enabling you to demonstrate control over who can access your APIs and the specific data they can access.
Improve governance by enforcing consistent access control policies across your API landscape. Adhering to the same security standards can reduce confusion and potential vulnerabilities.
Keep your agility! Quickly define and modify access rules, and reuse existing access policies across APIs and API versions.

Traefik Hub supports the growing complexity of your API and access control needs. As your API landscape evolves, you can manage the increasing complexity of access requirements without sacrificing security or efficiency.

In the next section, we'll showcase example scenarios demonstrating how granular API access control can be applied to address specific security challenges.

Example: Protecting Sensitive Data in a Healthcare API

Imagine a healthcare provider utilizing an API to manage patient data. This API likely contains sensitive information, such as medical records, prescriptions, and insurance details. While specific doctors and nurses require access to this data to provide care, it's crucial to restrict access to unauthorized individuals.

Traditionally, without granular access control, the provider might have only two options:

Grant all-or-nothing access: This approach exposes all data to all authorized users, posing significant security risks if unauthorized access occurs
Implementing complex custom business logic: This can be time-consuming to develop and maintain, especially as the API and its users evolve.

With Traefik Hub's granular API access control, the provider can achieve precise control by defining fine-grained API access rules:

Limit access to specific patient data API endpoints with URI path rules based on user roles. For example, doctors can access detailed medical records, while nurses can only view basic information.
Restrict access to specific HTTP methods. For example, allow only GET requests for read-only access and disallow modification methods like PUT or DELETE for nurses.
Mix and match these to create more advanced rules.

Let’s see the following configuration example we want to express for an Admin API that is versioned with two versions and an unversioned Patient API.

Rule Placement	Group	URI Path	HTTP Method
API Version	admin	/v1/admin (prefix)	*
API Version	admin-beta	/v1/admin (prefix) /v2/admin (prefix)	*
API	nurse	/patients (strict) /patients/[0-9]+$ (regex)	GET GET
API	doctor	/patients (prefix) /.* (regex)	GET, POST, PUT, DELETE GET

The Admin API has two versions defined using URL path-based versioning:
- The regular admin group can access everything on the current 1st version.
- The beta tester admin group can access everything on both the current and the upcoming v2 version.
The patient API exposes a /patients endpoint with a sub-path /patients/:id to access basic info of specific patients and a /patients/:id/details endpoint to get all the details. All of these support modifying and deleting the available data and creating new records.
- Nurses can only view basic information. They can list patients with /patients using strict URI path matching to limit access only to the list endpoint and can access basic info with /patients/:id.
- However, doctors can access full medical records, meaning everything under /patients like /patients/:id and /patients/:id/details using URI path prefix matching.
On the other hand, besides the Patient API, doctors can access all Admin API versions with read-only permissions to retrieve basic information about the hospital administration.

Let’s see the examples expressed as Traefik Hub CRDs. The relevant additions of granular API access control are highlighted.


---
apiVersion: hub.traefik.io/v1alpha1
kind: API
metadata:
  name: admin-api
  namespace: apps
  labels:
    area: health
spec:
  pathPrefix: /admin
  currentVersion: admin-api-v1
---
apiVersion: hub.traefik.io/v1alpha1
kind: APIVersion
metadata:
  name: admin-api-v1
  namespace: apps
  labels:
    area: health
spec:
  apiName: admin-api
  release: v1.0.0
  title: "Title of Admin API v1"
  routes:
    - pathPrefix: /v1
  stripPathPrefix: true
  service:
    name: admin-service-v1
    port:
      number: 8080
    openApiSpec:
      path: /openapi.json
      operationSets:                  # A new block from here
        - name: admin-ops-v1
          matchers:
            - path: /admin
        - name: read-all
          matchers:
            - methods:
                - GET
---
apiVersion: hub.traefik.io/v1alpha1
kind: APIVersion
metadata:
  name: admin-api-v2
  namespace: apps
  labels:
    area: health
spec:
  apiName: admin-api
  release: v2.0.0
  title: "Title of the beta Admin API v2"
  routes:
    - pathPrefix: /v2
  stripPathPrefix: true
  service:
    name: admin-service-v2
    port:
      number: 8080
    openApiSpec:
      path: /openapi.json
      operationSets:                  # A new block from here
        - name: admin-ops-v2
          matchers:
            - path: /admin
        - name: read-all
          matchers:
            - methods:
                - GET
---
apiVersion: hub.traefik.io/v1alpha1
kind: API
metadata:
  name: patient-api
  namespace: apps
  labels:
    area: health
spec:
  pathPrefix: /patients
  service:
    name: patient-service
    port:
      number: 8080
    openApiSpec:
      path: /openapi.json
      operationSets:                  # A new block from here
        - name: nurse-ops
          matchers:
            - path: /patients
              methods:
                - GET
            - pathRegex: "/patients/[0-9]+$"
              methods:
                - GET
        - name: doctor-ops
          matchers:
            - pathPrefix: /patients
              methods:
                - GET
                - POST
                - PUT
                - DELETE
        - name: read-all
          matchers:
            - methods:
                - GET

First, we define the Admin API and its two versions with operation sets specific to that version. Note that you don’t need to add the version matcher to the operation set, it will automatically apply—i.e., we only define /admin, and depending on the version, it will apply to /v1/admin and /v2/admin. There is also an operation set allowing read access on both versions, using the same operation set name to be reusable across even multiple APIs when we give access to users. On the Patient API, we define the nurse and doctor operation sets with explicit rules as to who can access what. The generic read-all set is also present here, extending to multiple APIs.

Then we define our API Access policies to match the user groups with the APIs, API Versions, and filter for the operation sets.


---
apiVersion: hub.traefik.io/v1alpha1
kind: APIAccess
metadata:
  name: admin-access
  labels:
    area: health
spec:
  groups:
 - admin                             # Note the admin group
  apis:
    - name: admin-api                # Has Access to the Admin API
      namespace: apps
  operationFilter:
    include:
      - admin-ops-v1                 # With the v1 operation set
---
apiVersion: hub.traefik.io/v1alpha1
kind: APIAccess
metadata:
  name: admin-beta-access
  labels:
    area: health
spec:
  groups:
    - admin-beta                     # Note the beta tester admin group
  apis:
    - name: admin-api                # Has access to the Admin API
      namespace: apps
  operationFilter:
    include:
      - admin-ops-v1                 # With the v1 operation set as regular admins
      - admin-ops-v2                 # And the new beta features of v2
---
apiVersion: hub.traefik.io/v1alpha1
kind: APIAccess
metadata:
  name: nurse-access
  labels:
    area: health
spec:
  groups:
    - nurse                          # Note the nurse group
  apis:
    - name: patient-api              # Has access to the Patient API
      namespace: apps
  operationFilter:
    include:
      - nurse-ops                    # With the restricted operations allowed to
---
apiVersion: hub.traefik.io/v1alpha1
kind: APIAccess
metadata:
  name: doctor-access
  labels:
    area: health
spec:
  groups:
    - doctor                         # Note the doctor group
  apiSelector:
    matchLabels:
      area: health                   # Can access APIs (current+future) with this label
  operationFilter:
    include:
      - doctor-ops                   # But restricted to operations defined for doctors
      - read-all                     # and read-all operations over multiple APIs

What stands out here is that the beta admin group can access two operation sets across the two API versions. In contrast, the regular admin group will only be granted access to the first version of the API. Nurses can only access the nurse operations, that’s simple. However, the policy for doctors is defined using a Kubernetes-native label selector to select all APIs that match the health label. This way, the filter for the doctor-ops operation will apply to the Patient API, and the read-all operation filter will be used throughout the two API versions of the Admin API. Since the read-all operation is also present on the Patient API, but the doctor-ops provide extended access to doctors, the broader rule overrides it.

When the Admin API v2 becomes stable, we could deprecate the v1 version to have only read-only access by modifying the related operation set and the regular admins’ access policy. Showing only the changes below:


# Admin API v1
operationSets:
  - name: admin-ops-v1
    matchers:
      - path: /admin
        Methods:                    # New line
          - GET                     # New line

# Regular Admin Access
operationFilter:
  include:
    - admin-ops-v1
    - admin-ops-v2                  # New line

In case a new API is added later with the same health label, that API will not grant automatic access to doctors to prevent data leaks, even though the label selector applies. Doctors can only gain access if the doctor-ops is also defined on that new API or if it defines some other operations that will be explicitly added to the doctors’ API access policy.

We hope these examples shed light on the flexibility of Traefik Hub’s new granular API access control solution with operation sets and filters.

Conclusion: Take Control of Your API Security

In today's API-driven landscape, robust security measures are essential. Traditional, all-or-nothing access control approaches leave organizations vulnerable to data breaches, compliance gaps, and operational inefficiencies. Traefik Hub's granular API access control empowers you to address these challenges head-on. Gain the control you need to secure your APIs, optimize developer workflows, and build a foundation for secure and thriving digital interactions.

Ready to learn more? Dive deeper into our documentation of operation set definitions for API & API Version and use them in operation filters in the API Access CRD.