Announcing NGINX Plus R14<\/p>\n
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<\/a>.<\/p>\n 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.<\/p>\n Additional NGINX Plus R14 features include: <\/p>\n NGINX Plus R14 has the following differences in behavior from the previous release:<\/p>\n Deployers of APIs and microservices are turning to the JSON Web Token (JWT, pronounced \u201cjot\u201d) 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.<\/p>\n 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).<\/p>\n A JWT payload may contain additional \u201cnested\u201d 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. <\/p>\n Considering the following JWT payload: <\/p>\n <\/code><\/p>\n In the above JWT, map $jwt_groups $isAdmin { server { auth_jwt \"closed site\"; location \/ { location \/admin { <\/code><\/p>\n Here are more details on how this configuration works:<\/p>\n 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.<\/p>\n In the above code example, using the Click here<\/a> for more information on all the configuration directives available for use to authenticate JWTs with NGINX Plus.<\/p>\n 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:<\/p>\n For example, you can configure NGINX Plus R14 to only accept JSON web tokens signed with the RS512 algorithm:<\/p>\n auth_jwt \"closed site\"; location \/ { <\/code><\/p>\n In this case, if the JWT has not been signed by the RS512 algorithm, NGINX will not proxy the request, and will return a Note<\/strong>: JWT support is exclusive to NGINX Plus.<\/p>\n NGINX Plus R13 introduced the Key-Value store module for HTTP<\/a>, 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<\/a>. <\/p>\n NGINX Plus R14 has extended the support for the Key-Value store API to the stream module<\/a>, so the same Key-Value pair capabilities are available for TCP\/UDP applications. <\/p>\n Dynamically reconfiguring the Key-Value store in the stream context is implemented in NGINX Plus R14 as part of the NGINX Plus API<\/a>.<\/p>\n Note<\/strong>: The Key-Value store and API are exclusive to NGINX Plus.<\/p>\n 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.<\/p>\n 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.<\/p>\n The nginScript shell example below demonstrates how to parse and extract JSON data using built-in object syntax. <\/p>\n v. -> the properties and prototype methods of v. >> var my_data = '{\"colors\":[{\"name\":\"red\",\"fancy\":\"brick dust\"}, {\"name\":\"blue\",\"fancy\":\"sea spray\"}]}'; <\/code><\/p>\n Node.js, the most popular server-side JavaScript implementation, provides built-in methods to access the OS filesystem<\/a> (client-side JavaScript doesn\u2019t 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: <\/p>\n This nginScript shell example shows how nginScript can be used to read file contents into a variable. <\/p>\n v. -> the properties and prototype methods of v. >> var fs = require('fs'); <\/code><\/p>\n To further help developers with debugging and troubleshooting, a wide range of error objects is now available: <\/p>\n 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. <\/p>\n <\/code><\/p>\n Learn how to get started with nginScript<\/a> in our introductory blog post. <\/p>\n NGINX Plus R13<\/a> introduced the NGINX Plus API<\/a>, allowing users to have access to real-time monitoring and metrics in a JSON format. In NGINX Plus R14, a new NGINX Plus dashboard<\/a> 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. <\/p>\n 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. <\/p>\n Configuration for the existing NGINX Plus dashboard looks like this:<\/p>\n <\/code><\/p>\n To migrate your existing NGINX Plus instances to the new NGINX Plus dashboard, replace your existing status locations with this:<\/p>\n # Catch users of old dashboard <\/code><\/p>\n Remember to migrate all existing access controls from the For more information about the new NGINX Plus API, please see the NGINX Plus R13 announcement<\/a>.<\/p>\n Note<\/strong>: The NGINX Plus dashboard is exclusive to NGINX Plus.<\/p>\n 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 \u201cdraining\u201d mode. To do this, send a PATCH request to the API resource for the relevant server, with NGINX Plus R14 extends this functionality to file-based configuration by providing a <\/code><\/p>\n 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 With NGINX Plus R14, we\u2019re pleased to announce a technology preview of a forthcoming capability for state sharing across a cluster of NGINX Plus instances. The sticky learn<\/a> method of session affinity is implemented to demonstrate the benefits of distributing session data that would otherwise be individually managed by each instance.<\/p>\n 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. <\/p>\n Notes:<\/strong> <\/p>\n Note<\/strong>: Clustering support and sticky learn session affinity are both exclusive to NGINX Plus.<\/p>\n NGINX Plus R14 also includes the following enhancements:<\/p>\n NGINX Plus R14 includes improved authentication capabilities for your client applications, additional clustering capabilities, nginScript enhancements, and notable bug fixes<\/a>. 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.<\/p>\n If you\u2019re running NGINX Plus, we strongly encourage you to upgrade to Release 14 as soon as possible. You\u2019ll pick up a number of fixes and improvements, and upgrading will help NGINX to help you when you need to raise a support ticket. <\/p>\n Please carefully review the new features and changes in behavior described in this blog post before proceeding with the upgrade.<\/p>\n If you haven\u2019t tried NGINX Plus<\/a>, 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<\/a>. See for yourself how NGINX Plus can help you deliver and scale your applications. <\/p>\n The post Announcing NGINX Plus R14<\/a> appeared first on NGINX<\/a>.<\/p>\n Source: Announcing NGINX Plus R14<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" 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) – [ more… ]<\/a><\/p>\n<\/div>","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[169],"tags":[652],"class_list":["post-21147","post","type-post","status-publish","format-standard","hentry","category-news","tag-nginx"],"amp_enabled":true,"_links":{"self":[{"href":"https:\/\/jirak.net\/wp\/wp-json\/wp\/v2\/posts\/21147","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/jirak.net\/wp\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/jirak.net\/wp\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/jirak.net\/wp\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/jirak.net\/wp\/wp-json\/wp\/v2\/comments?post=21147"}],"version-history":[{"count":1,"href":"https:\/\/jirak.net\/wp\/wp-json\/wp\/v2\/posts\/21147\/revisions"}],"predecessor-version":[{"id":21148,"href":"https:\/\/jirak.net\/wp\/wp-json\/wp\/v2\/posts\/21147\/revisions\/21148"}],"wp:attachment":[{"href":"https:\/\/jirak.net\/wp\/wp-json\/wp\/v2\/media?parent=21147"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/jirak.net\/wp\/wp-json\/wp\/v2\/categories?post=21147"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/jirak.net\/wp\/wp-json\/wp\/v2\/tags?post=21147"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\n
stream<\/code> context. <\/li>\nChanges in Behavior<\/h2>\n
\n
upstream_conf<\/code> 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<\/a>. <\/li>\nNGINX Plus R14 Features in Detail<\/h2>\n
JWT Enhancements<\/h3>\n
Support for Nested JWT Claims and Array Data<\/h4>\n
{
\n \"exp\": 1513429677,
\n \"sub\": \"xample@example.com\",
\n \"aud\": \"nginx\",
\n \"attributes\": {
\n \"name\": \"Xavier Ample\",
\n \"room\": \"A123\",
\n \"dept\": \"Demonstrations\"
\n },
\n \"groups\": [
\n \"Administrator\",
\n \"Foobar\",
\n \"Bazpub\"
\n ]
\n}<\/pre>\nattributes<\/code> is a \u201cnested claim\u201d object and groups<\/code> 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<\/code> object to the backend. <\/p>\nauth_jwt_claim_set $jwt_groups groups; # Array value will join as comma-separated values
\nauth_jwt_claim_set $jwt_real_name attributes name; # This value is two levels deep<\/p>\n
\n\t\"~bAdministratorb\" 1; # Appears within word boundaries (b) of CSV list
\n\tdefault 0;
\n}<\/p>\n
\n listen 443 ssl;
\n #ssl_*; # Config for SSL\/TLS termination<\/p>\n
\n auth_jwt_key_file jwk.json;<\/p>\n
\n proxy_set_header X-RealName $jwt_real_name; # Pass real name as header
\n proxy_set_header X-Subject $jwt_claim_sub; # L1 claims set automatically
\n proxy_pass http:\/\/my_backend;
\n }<\/p>\n
\n if ( $isAdmin = 0 ) {
\n return 403; # Forbidden
\n }
\n proxy_pass http:\/\/my_backend;
\n }
\n}<\/pre>\n\n
auth_jwt_claim_set<\/code><\/a> directive, we set the $jwt_groups<\/code> 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<\/code>.<\/li>\nmap<\/code><\/a> directive, we search through the list of groups for the Administrator<\/code> keyword. If present, the user is deemed an administrator and $isAdmin<\/code> is set to 1. Otherwise $isAdmin<\/code> is set to 0.<\/li>\nlocation<\/code><\/a> block for the URI \/admin<\/strong> checks the $isAdmin<\/code> variable. If 0, NGINX will return a 403 Forbidden<\/code> status code back to the client.<\/li>\n<\/ul>\nauth_jwt_claim_set<\/code><\/a> directive, we set the $jwt_real_name<\/code> NGINX variable to the value of the name object within the attributes<\/code> claim. The proxy_set_header<\/code><\/a> directive will set the X-RealName HTTP header to the value of the name<\/code> object and proxy the request to my_backend<\/code>. <\/p>\nLonger Key Sizes for JWT Signing Algorithms<\/h4>\n
\n
server {
\n listen 443 ssl;
\n #ssl_*; # Config for SSL\/TLS termination<\/p>\n
\n auth_jwt_key_file jwk.json;<\/p>\n
\n if ( $jwt_header_alg != RS512 ) {
\n return 401;
\n }
\n proxy_pass http:\/\/my_backend;
\n }
\n}<\/pre>\n401 Unauthorized<\/code> status code back to the client that issued the request. <\/p>\nKey-Value Store and API for Stream Module<\/h3>\n
nginScript Enhancements<\/h3>\n
JSON Object Support<\/h4>\n
$ njs
\ninteractive njscript<\/p>\n
\ntype console.help() for more information<\/p>\n
\n>> var my_object = JSON.parse(my_data);
\n>> my_object.colors[1].fancy;
\nsea spray
\n>><\/pre>\nFilesystem Access<\/h4>\n
\n
$ njs
\ninteractive njscript<\/p>\n
\ntype console.help() for more information<\/p>\n
\n>> var tz = fs.readFileSync('\/etc\/timezone', function(e) {if (e) {data = e;} });
\n>> tz
\nEurope\/London<\/pre>\nError Objects and Backtraces<\/h4>\n
Error, EvalError, InternalError, RangeError, ReferenceError, SyntaxError, TypeError, URIError<\/code><\/p>\n2017\/12\/12 01:52:08 [error] 43441#43441: *10 js exception: Error: No such file or directory
\n at native (native)
\n at my_function (:1)
\n at main (native)
\n, client: 127.0.0.1, server: , request: \"GET \/ HTTP\/1.1\", host: \"localhost:80\"<\/pre>\nNGINX Plus Dashboard for the New NGINX Plus API<\/h3>\n
location \/status {
\n status;
\n }
\n location = \/status.html {
\n root \/usr\/share\/nginx\/html;
\n }<\/pre>\n location \/api {
\n api write=on;
\n }
\n location = \/dashboard.html {
\n root \/usr\/share\/nginx\/html;
\n }<\/p>\n
\n location = \/status.html {
\n return 301 \/dashboard.html;
\n }<\/pre>\n\/status<\/code> location to the \/api<\/code> location. Examples include allow<\/code> \/ deny<\/code> directives and authentication controls.<\/p>\nDrain Upstream Server Directive (without API)<\/h3>\n
{\"drain\":true}<\/code>. <\/p>\ndrain<\/code> parameter to the upstream server directive<\/a>. <\/p>\nupstream my_backend {
\n server 10.0.0.1;
\n server 10.0.0.2;
\n server 10.0.0.3 drain;
\n}
\n<\/pre>\nserver<\/code> directives completely.<\/p>\nClustering Support for Sticky Learn (Technology Preview)<\/h3>\n
\n
Additional Features<\/h3>\n
\n
Upgrade or Try NGINX Plus<\/h2>\n