Announcing NGINX Plus R14

2017-12-12 KENNETH NEWS 0

Announcing NGINX Plus R14

We’re pleased to announce that NGINX Plus R14 is now available to our NGINX Plus subscribers. NGINX Plus is the only all-in-one load balancer, content cache, and web server. NGINX Plus R14 is based on the open source NGINX software and previous NGINX Plus releases. The new release also includes authentication and clustering enhancements, additional features, bug fixes, and our award-winning 24-hour support.

With NGINX Plus R14, you can enforce access controls using JSON web tokens (JWT). With new support for nested JWT claims, NGINX Plus can allow or grant access based on group membership information nested inside a JWT. Native JWT authentication support, first introduced in NGINX Plus R10, enables NGINX Plus to be used as an authentication gateway for your APIs and applications.

Additional NGINX Plus R14 features include:

  • Extended clustering support (technology preview) – With this technology preview, NGINX Plus can now share state information across a cluster. We invite you to test out this new functionality with the sticky learn session persistence method. In future releases, we’ll be expanding NGINX Plus clustering capabilities.
  • Longer JWT key sizes – In addition to support for nested JWT claims and array data, longer key sizes up to 512 bits are now supported for JWT signing algorithms. This provides more security and flexibility when validating JWTs.
  • Stream Key-Value store and API – The powerful Key-Value store and API introduced in our previous release can now be used with TCP and UDP applications in the stream context.
  • nginScript enhancements – nginScript, which enables you to run JavaScript code on NGINX, now has additional language support for the JSON object. This lets you parse and extract information from JSON responses received from backend APIs natively and use Node.js-style methods to access your filesystem. nginScript also now provides backtraces for a wide range of exception/error objects when they occur, to facilitate debugging and troubleshooting.
  • More features – NGINX Plus also features an updated NGINX Plus dashboard, a new SSL variable, and upstream server draining.

Changes in Behavior

NGINX Plus R14 has the following differences in behavior from the previous release:

  • The NGINX Plus API has been upgraded to Version 2. Check the API compatibility documentation if you’re considering using new NGINX Plus API features.
  • The upstream_conf and extended status APIs have been deprecated as of the release of NGINX Plus R13. They have been superseded by the new NGINX Plus API, which is used by the new monitoring dashboard.
  • NGINX Plus is now available for Ubuntu 17.10 (Artful Aardvark).
  • NGINX Plus is no longer supported on Debian 7 (Wheezy).

NGINX Plus R14 Features in Detail

JWT Enhancements

Deployers of APIs and microservices are turning to the JSON Web Token (JWT, pronounced “jot”) standard for its simplicity and flexibility. A JWT is a compact and highly portable means of exchanging identity information. A JWT can be issued from a number of issuers, such as Okta, OneLogin, or a homegrown solution. NGINX Plus can then grant or deny access based on whether or not the user or API client has presented a valid JWT.

NGINX Plus R14 adds support for nested JWT claims and array data, as well as longer key sizes for JWT signing algorithms. This provides more flexibility and greater security when validating JSON web tokens (JWTs).

Support for Nested JWT Claims and Array Data

A JWT payload may contain additional “nested” information about the user, such as group membership, that can be used to authorize access to a resource. This helps avoid the need to query a database multiple times to authorize user requests.

Considering the following JWT payload: 

{

  "exp": 1513429677,

  "sub": "[email protected]",

  "aud": "nginx",

  "attributes": {

    "name": "Xavier Ample",

    "room": "A123",

    "dept": "Demonstrations"

  },

  "groups": [

    "Administrator",

    "Foobar",

    "Bazpub"

  ]

}

In the above JWT, attributes is a “nested claim” object and groups is an array. You can use the following configuration snippet to deny access to users who are not in the Administrator group and pass the name value from the attributes object to the backend. 

auth_jwt_claim_set $jwt_groups groups; # Array value will join as comma-separated values

auth_jwt_claim_set $jwt_real_name attributes name; # This value is two levels deep


map $jwt_groups $isAdmin {

	"~bAdministratorb" 1; # Appears within word boundaries (b) of CSV list

	default              0;

}


server {

    listen 443 ssl;

    #ssl_*; # Config for SSL/TLS termination


    auth_jwt "closed site";

    auth_jwt_key_file jwk.json;


    location / {

        proxy_set_header X-RealName $jwt_real_name; # Pass real name as header

        proxy_set_header X-Subject  $jwt_claim_sub; # L1 claims set automatically

        proxy_pass http://my_backend;

    }


    location /admin {

        if ( $isAdmin = 0 ) {

            return 403; # Forbidden

        }

        proxy_pass http://my_backend;

    }

}

Here are more details on how this configuration works:

  • Using the auth_jwt_claim_set directive, we set the $jwt_groups NGINX variable to the groups array defined in the JWT. The values in the array will be separated by commas and assigned to $jwt_groups.
  • Using the map directive, we search through the list of groups for the Administrator keyword. If present, the user is deemed an administrator and $isAdmin is set to 1. Otherwise $isAdmin is set to 0.
  • The location block for the URI /admin checks the $isAdmin variable. If 0, NGINX will return a 403 Forbidden status code back to the client.

With NGINX Plus R14, you can also create variables from nested JWT claims. The variables can then be put into HTTP headers before proxying them to backend servers.

In the above code example, using the auth_jwt_claim_set directive, we set the $jwt_real_name NGINX variable to the value of the name object within the attributes claim. The proxy_set_header directive will set the X-RealName HTTP header to the value of the name object and proxy the request to my_backend.

Click here for more information on all the configuration directives available for use to authenticate JWTs with NGINX Plus.

Longer Key Sizes for JWT Signing Algorithms

NGINX Plus R14 now supports 256-bit, 384-bit, and 512-bit signing keys for stronger signature validation and easier integration with identity and access management (IAM) products that use longer signing keys by default. The longer signing keys are available for all supported signature algorithms:

  • HMAC with SHA-2 (“HS”)
  • RSA PKCS #1 with SHA-2 (“RS”)
  • Elliptic Curve Digital Signature Algorithm (“ES”)

For example, you can configure NGINX Plus R14 to only accept JSON web tokens signed with the RS512 algorithm:

server {

    listen 443 ssl;

    #ssl_*; # Config for SSL/TLS termination


    auth_jwt "closed site";

    auth_jwt_key_file jwk.json;


    location / {

        if ( $jwt_header_alg != RS512 ) {

            return 401;

        }

        proxy_pass http://my_backend;

    }

}

In this case, if the JWT has not been signed by the RS512 algorithm, NGINX will not proxy the request, and will return a 401 Unauthorized status code back to the client that issued the request.

Note: JWT support is exclusive to NGINX Plus.

Key-Value Store and API for Stream Module

NGINX Plus R13 introduced the Key-Value store module for HTTP, allowing you to create, modify, and purge Key-Value pairs in one or more shared memory zones on the fly. One great use case for the Key-Value store API is using it with fail2ban to create a dynamic IP blacklist.

NGINX Plus R14 has extended the support for the Key-Value store API to the stream module, so the same Key-Value pair capabilities are available for TCP/UDP applications.

Dynamically reconfiguring the Key-Value store in the stream context is implemented in NGINX Plus R14 as part of the NGINX Plus API.

Note: The Key-Value store and API are exclusive to NGINX Plus.

nginScript Enhancements

nginScript is a JavaScript-based scripting language for NGINX Plus. In NGINX Plus R14, the capabilities of nginScript have been extended to further improve programmability. An updated dynamic module package for nginScript now provides the following new enhancements.

JSON Object Support

The JavaScript JSON object is now available as a native object in nginScript. This provides a more convenient way of managing complex data structures, and also allows nginScript to parse and manipulate JSON responses received from backend APIs.

The nginScript shell example below demonstrates how to parse and extract JSON data using built-in object syntax. 

$ njs

interactive njscript


v. -> the properties and prototype methods of v.

type console.help() for more information


>> var my_data = '{"colors":[{"name":"red","fancy":"brick dust"}, {"name":"blue","fancy":"sea spray"}]}';

>> var my_object = JSON.parse(my_data);

>> my_object.colors[1].fancy;

sea spray

>>

Filesystem Access

Node.js, the most popular server-side JavaScript implementation, provides built-in methods to access the OS filesystem (client-side JavaScript doesn’t allow filesystem access). With NGINX Plus R14, Node.js filesystem methods can now be used in nginScript to read and write files, allowing you to customize your application delivery workflow. The following operations are permitted:

  • Read: fs.readFile, fs.readFileSync
  • Write: fs.writeFile, fs.writeFileSync
  • Append: fs.appendFile, fs.appendFileSync

This nginScript shell example shows how nginScript can be used to read file contents into a variable. 

$ njs

interactive njscript


v. -> the properties and prototype methods of v.

type console.help() for more information


>> var fs = require('fs');

>> var tz = fs.readFileSync('/etc/timezone', function(e) {if (e) {data = e;} });

>> tz

Europe/London

Error Objects and Backtraces

To further help developers with debugging and troubleshooting, a wide range of error objects is now available:

Error, EvalError, InternalError, RangeError, ReferenceError, SyntaxError, TypeError, URIError

Additionally, nginScript now provides backtraces for errors and exceptions. The following entry from the error log shows a simple backtrace for a failed system operation. 

2017/12/12 01:52:08 [error] 43441#43441: *10 js exception: Error: No such file or directory

    at native (native)

    at my_function (:1)

    at main (native)

, client: 127.0.0.1, server: , request: "GET / HTTP/1.1", host: "localhost:80"

Learn how to get started with nginScript in our introductory blog post.

NGINX Plus Dashboard for the New NGINX Plus API

NGINX Plus R13 introduced the NGINX Plus API, allowing users to have access to real-time monitoring and metrics in a JSON format. In NGINX Plus R14, a new NGINX Plus dashboard is included that uses this API. This new dashboard uses the NGINX Plus API extended status functionality to provide more than 80 monitoring metrics to the user in real time.

The old APIs used by dashboards in previous versions of NGINX Plus are deprecated. They will continue to be shipped with NGINX Plus in this release, R14, and the next release, R15. The old dashboard and deprecated APIs will then be removed with NGINX Plus R16.

Configuration for the existing NGINX Plus dashboard looks like this:

    location /status {

        status;

    }

    location = /status.html {

        root /usr/share/nginx/html;

    }

To migrate your existing NGINX Plus instances to the new NGINX Plus dashboard, replace your existing status locations with this:

    location /api {

        api write=on;

    }

    location = /dashboard.html {

        root /usr/share/nginx/html;

    }


    # Catch users of old dashboard

    location = /status.html {

        return 301 /dashboard.html;

    }

Remember to migrate all existing access controls from the /status location to the /api location. Examples include allow / deny directives and authentication controls.

For more information about the new NGINX Plus API, please see the NGINX Plus R13 announcement.

Note: The NGINX Plus dashboard is exclusive to NGINX Plus.

Drain Upstream Server Directive (without API)

Before taking a server offline, we want to prevent new connections, then allow existing active sessions to complete, leaving no active sessions remaining. You can execute this functionality with the NGINX Plus API by putting upstream servers into “draining” mode. To do this, send a PATCH request to the API resource for the relevant server, with {"drain":true}.

NGINX Plus R14 extends this functionality to file-based configuration by providing a drain parameter to the upstream server directive. 

upstream my_backend {

        server  10.0.0.1;

        server  10.0.0.2;

        server  10.0.0.3 drain;

}

After reloading the NGINX configuration, the upstream server with IP 10.0.0.3 will be in draining mode. The configuration can later be modified to remove the third of the three server directives completely.

Clustering Support for Sticky Learn (Technology Preview)

With NGINX Plus R14, we’re pleased to announce a technology preview of a forthcoming capability for state sharing across a cluster of NGINX Plus instances. The sticky learn method of session affinity is implemented to demonstrate the benefits of distributing session data that would otherwise be individually managed by each instance.

Support for sticky learn is provided as a technology preview. The technology preview is provided as a separate installable package and is available on request. Please contact your NGINX sales representative for access.

Notes:

  1. The sticky learn clustering functionality is in preview status and as such is not suitable for use in production. If state sharing across a cluster is an important requirement for your environment then we encourage you to test the technology preview and provide feedback to NGINX on how well it meets your needs.
  2. Technology preview packages are available for CentOS/RHEL 7, Debian 8/9, and Ubuntu 16.04, 16.10, 17.10.

Note: Clustering support and sticky learn session affinity are both exclusive to NGINX Plus.

Additional Features

NGINX Plus R14 also includes the following enhancements:

  • Resolver state persistence across reloads – Saves your list of upstream DNS records when reloading NGINX Plus so no request will find an empty list of upstream IP addresses.
  • New SSL client certificate variable – The variable $ssl_client_escaped_cert is a new embedded NGINX variable providing you a safe and convenient way to encode your client certificates in an HTTP header so you can send them to your backend applications. The variable is URL-encoded.

Upgrade or Try NGINX Plus

NGINX Plus R14 includes improved authentication capabilities for your client applications, additional clustering capabilities, nginScript enhancements, and notable bug fixes. In particular, NGINX Plus R13 introduced a bug for active health checks whereby an old worker process might perform health checks indefinitely. This has been resolved with NGINX Plus R14.

If you’re running NGINX Plus, we strongly encourage you to upgrade to Release 14 as soon as possible. You’ll pick up a number of fixes and improvements, and upgrading will help NGINX to help you when you need to raise a support ticket.

Please carefully review the new features and changes in behavior described in this blog post before proceeding with the upgrade.

If you haven’t tried NGINX Plus, we encourage you to try it out – for web acceleration, load balancing, and application delivery, or as a fully supported web server with enhanced monitoring and management APIs. You can get started for free today with a 30-day evaluation. See for yourself how NGINX Plus can help you deliver and scale your applications.

The post Announcing NGINX Plus R14 appeared first on NGINX.

Source: Announcing NGINX Plus R14

About KENNETH 19688 Articles
지락문화예술공작단

Be the first to comment

Leave a Reply

Your email address will not be published.


*


이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.