Release Notes

These release notes list and describe the new features, enhancements, and resolved issues in NGINX Management Suite API Connectivity Manager.

See Also:
See the Known Issues page for a list of known issues in the API Connectivity Manager and possible workarounds.

1.2.0

October 18, 2022

Upgrade Paths

API Connectivity Manager 1.2.0 supports upgrades from these previous versions:

  • 1.0.0 – 1.1.1
See Also:
Refer to the Upgrade Guide for important information and steps to follow when upgrading API Connectivity Manager.

Dependencies with Instance Manager

API Connectivity Manager (ACM) depends on the platform capabilities of Instance Manager. The following table lists the minimum versions of Instance Manager required for ACM:

API Connectivity Manager Instance Manager
ACM 1.1 and later NIM 2.4 and later
ACM 1.0 NIM 2.3 and later

For new features in ACM to work correctly, ACM may need to install or upgrade Instance Manager to a specific minimum version, as follows:

  • If Instance Manager isn’t installed, ACM will install the latest version of Instance Manager for you.
  • If the installed version of Instance Manager is below the minimum version required for ACM, ACM will upgrade Instance Manager to the latest version.
  • If Instance Manager is at or above the minimum required version for ACM, ACM will leave Instance Manager unchanged.
Important:
If you’re installing ACM in an offline environment and the minimum required version of Instance Manager is not installed, the ACM installer will exit. You’ll need to install Instance Manager manually before installing ACM.

What’s New

  • Secure API access with OAuth2 tokens

    API Owners can restrict access to their APIs with OAuth2 tokens by swapping an opaque token for claims or a JWT token to be proxied to the backend service. The policy can be configured to grant access to APIs after having the tokens introspected. In addition, the claims in the token can be extracted and forwarded to the backend service.

    Tip:
    Learn how to set up an OAuth2 Introspection policy with Keycloak as the authorization server.
  • Restrict access to APIs based on IP address

    Using the ACL-IP policy, API owners can now restrict access to APIs based on IP addresses. APIs can be protected by quickly blocking rogue requests from certain IPs or allowing access to only known IPs.

  • Support for HTTP/2

    To improve the performance and efficiency of client-server interactions, HTTP/2 can be enabled on the API proxies. With HTTP/2 enabled, API Proxies will continue to maintain backward compatibility with older browsers.

  • Publish and manage gRPC services - preview release

    Important:
    This is a preview feature for you to try out. You shouldn’t use preview features for production purposes.

    To handle gRPC traffic, you can now publish and manage gRPC proxies.

    Publish gRPC proxies and route gRPC traffic to support the following use cases:

    • Simple RPC (single request‑response)
    • Response‑streaming RPC
    • Request‑streaming RPC
    • Bidirectional‑streaming RPC
    • Route to all services in a gRPC service package
    • Route to a single gRPC service
    • Route to individual gRPC methods
    • Route to multiple gRPC services
    • Respond to errors with custom gRPC error response format policy
  • Out-of-the-box protection for Developer Portals

    Developer Portals are now deployed with out-of-the-box protection against rapid requests/overuse and server fingerprinting:

    1. Protection against server fingerprinting

      The proxy response header policy is now applied by default to a Developer Portal cluster. The default policy disables server tokens from being returned in the proxy response.

    2. Protection against rapid requests and over-use

      To protect the portal application, the default rate limit policy limits the number of requests a client can make in a time period. Platform admins can customize the policy to meet their SLAs.

  • Support for multi-host deployment pattern for Developer Portals

    Developer Portals can support multiple deployment patterns. The portal backend API service can be scaled to multiple hosts and can be load-balanced using host IP addresses or internal DNS.

    To support the deployment patterns, configs -> proxyConfig -> backends object has been introduced in the Portal Proxy runtime. The existing backend object in the proxyCluster object of the Portal Proxy runtime is being deprecated and will not be available in the next major release version.

  • Enhanced API documentation on Developer Portals

    The API documentation published to the Developer Portal now displays detailed security schema information for each API.

  • Express API payload size with unit of measure

    The maximum allowed size for the client request body can now be configured in bytes, kilobytes(K) or megabytes(M).

    The maxRequestBodySizeLimit attribute of the policy is deprecated and will be removed in the next major API Connectivity Manager release. Size is the new attribute that supports bytes, megabytes(M), and kilobytes(K). The default setting is 1M.

  • Database backup included in support packages

    The Developer Portal support package now includes the option to back up the PostgreSQL database.

  • Improved visualizations for resource credentials

    API owners can now view the origin of resource credentials. The source field indicates where the credentials were created. For security reasons, the credentials created on the Developer Portal will be masked, but the API owners can view the origin of the resource credentials.

Resolved Issues

This release fixes the following issues. To view the history for an issue, see the Known Issues list.

  • To see updates to the Listener’s table, forced refresh of the cluster details page is required. (36540)

  • Using labels to specify the backend is partially available. (36317)

  • Ratelimit policy cannot be applied with OAuth2 JWT Assertion policy. (36095)

  • Unable to delete an environment that is stuck in a Configuring state. (35546)

  • Enums are not supported in Advanced Routing. (34854)

  • Credentials endpoint is disabled by default. (35630)


1.1.1

August 31, 2022

Upgrade Paths

API Connectivity Manager 1.1.1 supports upgrades from these previous versions:

  • 1.0.0 – 1.1.0
See Also:
Refer to the Upgrade Guide for important information and steps to follow when upgrading API Connectivity Manager.

Dependencies with Instance Manager

API Connectivity Manager (ACM) depends on the platform capabilities of Instance Manager. The following table lists the minimum versions of Instance Manager required for ACM:

API Connectivity Manager Instance Manager
ACM 1.1 and later NIM 2.4 and later
ACM 1.0 NIM 2.3 and later

For new features in ACM to work correctly, ACM may need to install or upgrade Instance Manager to a specific minimum version, as follows:

  • If Instance Manager isn’t installed, ACM will install the latest version of Instance Manager for you.
  • If the installed version of Instance Manager is below the minimum version required for ACM, ACM will upgrade Instance Manager to the latest version.
  • If Instance Manager is at or above the minimum required version for ACM, ACM will leave Instance Manager unchanged.
Important:
If you’re installing ACM in an offline environment and the minimum required version of Instance Manager is not installed, the ACM installer will exit. You’ll need to install Instance Manager manually before installing ACM.

What’s New

  • Bug fixes

Resolved Issues

This release fixes the following issues. To view the history for an issue, see the Known Issues list.

  • Advanced routing ignores the Context Root setting for backend proxies (36775)

  • Traffic is not secured between the API Proxy and backend servers (36714)

  • OIDC policy doesn’t work with Auth0 Identity Providers (36058)


1.1.0

August 18, 2022

Upgrade Paths

API Connectivity Manager 1.1.0 supports upgrades from these previous versions:

  • 1.0.0
See Also:
Refer to the Upgrade Guide for important information and steps to follow when upgrading API Connectivity Manager.

Dependencies with Instance Manager

API Connectivity Manager (ACM) depends on the platform capabilities of Instance Manager. The following table lists the minimum versions of Instance Manager required for ACM:

API Connectivity Manager Instance Manager
ACM 1.1 and later NIM 2.4 and later
ACM 1.0 NIM 2.3 and later

For new features in ACM to work correctly, ACM may need to install or upgrade Instance Manager to a specific minimum version, as follows:

  • If Instance Manager isn’t installed, ACM will install the latest version of Instance Manager for you.
  • If the installed version of Instance Manager is below the minimum version required for ACM, ACM will upgrade Instance Manager to the latest version.
  • If Instance Manager is at or above the minimum required version for ACM, ACM will leave Instance Manager unchanged.
Important:
If you’re installing ACM in an offline environment and the minimum required version of Instance Manager is not installed, the ACM installer will exit. You’ll need to install Instance Manager manually before installing ACM.

What’s New

This release includes the following updates:

  • Advanced Cluster Management

    Including more than one proxy cluster with the same hostname in an environment replicates configuration across all clusters and assists with blue-green deployments. With advanced cluster management, you can use a load balancer in front of the clusters to slowly move to the newer version of the API gateway cluster. For example, one cluster may belong to NGINX Plus version R26 and another to R27. See the Technical Specifications.

  • Advanced Routing feature is available now

    Advanced routing feature is available now. You can use it to publish an API Proxy and route specific URIs/endpoints precisely to a backend service. Advanced routing with OAS Specification allows you to import a specification file, parse all the URIs/endpoints in the file and publish API proxy by routing each URI/endpoint precisely to a backend service. To use the advanced routing feature without an OAS specification file, add the URI/endpoints while publishing the API proxy. See the Advanced Configurations section.

  • SQLite is supported for Developer Portal

    SQLite is now supported as a database for Developer Portal installations.

  • Support for NGINX Plus Release 27 (R27)

    This release supports NGINX Plus Release 27 (R27) version for Data Plane instances. See the Technical Specifications.

Resolved Issues

This release fixes the following issues. To view the history for an issue, see the Known Issues list.

  • JWT Assertion policy accepts an empty string value for tokenName property (35419)

  • Environment is in a premature success state even though all proxy clusters may not be onboarded (35430)

  • Cannot add, remove, or edit proxy clusters from an environment that has a published API proxy (35463)

  • Features in the web interface are not displayed after uploading license (35525)

  • DEVPORTAL_OPTS in /etc/{default,sysconfig}/nginx-devportal does not work if value has multiple words (36040)


1.0.0

July 19, 2022

What’s New

This release introduces the following features:

  • Create and manage isolated workspaces for business units, development teams, etc., so each team can develop and deploy at its own pace without affecting other teams.
  • Create and manage API infrastructure in isolated workspaces.
  • Create and manage production and non-production environments within team workspaces and control who can access APIs at various lifecycle stages. For example, keep APIs under development private and publish production-ready APIs for public access.
  • Enforce uniform security policies across all workspaces by applying global policies.
  • Create Developer Portals that align with your brand, with custom color themes, logos, and favicons.
  • On-board your APIs, publish to an API Gateway cluster, and publish your API documentation to the Developer Portal.
  • Let teams apply policies to their API proxies to provide custom quality of service for individual applications.
  • On-board API documentation by uploading an OpenAPI spec.
  • Publish your API docs to a Developer Portal without giving the public access to your API.
  • Monitor system and traffic metrics at the instance level.
  • Self-service credential issuance for API Keys and Basic Authentication.
  • Test API calls to your system using the “Try it out” feature in the Developer Portal.