Site icon 지락문화예술공작단

Announcing NGINX Plus R14

KENNETH

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:

Changes in Behavior

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

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": "xample@example.com",

  "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:

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:

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:

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:

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

Exit mobile version