F5 Labs - Index

ようこそ

ようこそ、 NGINX Controller labへ

はじめに

インストラクターより提供される手順に従ってラボを進めてください。すでにこのガイドを閲覧されている状況であれば、UDFの環境を実行しているかもしれません。

Important

このラボのすべての作業はWindows Jumphost(RDP)から行います。皆様のローカルのシステムに対するインストールや操作は必要ありません

“jumphost-1”というUDFインスタンスにRDPを使用し、adminアカウントでログインしてください。提供されるUDF環境によって画面のデザインが異なる場合がありますがご了承ください

Username Password

Administrator BZ8D8MCVR

Lab Topology

このラボ環境では主に以下のコンポーネントが実行されます

3 X NGINX Controller Instances (v3.x)
1 X Postgres Database Instance (NGINX Controllerで使用)
3 X NGINX Plus Instances w/ agents installed (CentOS 7)
1 X Application Servers (apps running in Docker on Ubuntu 18.04)
1 X Windows Domain Controller (Windows 2019 Server)
1 X Load Generator Instances (Ubuntu 18.04)

NGINX Controller Credentials

NGINXコントローラーは、ActiveDirectoryドメインコントローラーに対して認証を実行するように構成されています。このラボでは、次のアカウントを使用します。

Employee	Login UPN	Password	Active Directory Security Group
Peter Parker	peter@acmefinancial.net	`Peter123!@#`	nginx-controller-admins
Natasha Romanoff	natasha@acmefinancial.net	`Natasha123!@#`	nginx-controller-user
admin istrator (fallback account)	admin@acmefinancial.net	`Admin123!@#`	NA/Local User

このラボ環境でNGINXコントローラのRBAC機能を調査したい場合、以下のアカウントをご利用ください

Employee	Login UPN	Password	Active Directory Security Group
Wanda Maximoff	wanda@acmefinancial.net	`Wanda123!@#`	nginx-controller-admins
Clint Barton	clint@acmefinancial.net	`Clint123!@#`	nginx-controller-user
Luke Cage	luke@acmefinancial.net	`Luke123!@#`	nginx-controller-readers

Module 1 - Enterprise Features

このセクションでは、エンタプライズ環境で必要となる2つの機能を確認します。認証管理機能、冗長機能です。

Lab 1: 外部のActive DirectoryをAuthentication Providerとして指定する方法について紹介します
Lab 2: NGINX Controller クラスタに冗長性を持たせるため、新たにNGINX Controller インスタンスを追加する方法を紹介します
Lab 3: NGINX Controller に新たに管理対象となるNGINX Plusを追加する方法を紹介します

Lab 1 - Active Directory Authentication

このラボではActivce Directory認証で設定されている内容とRole Based Access Controlの設定に追加確認します。設定変更は行わず、設定済みの内容を確認します。

この機能により組織の既存環境で利用している認証のプロセスをNGINX Controllerに統合することが可能です

Important

想定時間: 5分

Note

このLabの手順はラボを実施する方がWindows jumphost – jumphost-1 から操作する手順を示しています。接続方法についてはこちらを参照ください。 F5 Labs - Index

Authentication Providersの設定を確認する

jumphostのChromeで開かれているNGINX Controllerの管理画面を操作します。証明書エラーが表示されている場合には適切に操作をして画面を開いてください
もし開かれていない場合、Chromeブラウザを開いてください
BookmarkからNGINX Controller UIにアクセスしてください
NGINX Controller のadmin accountである、Peter Parker でログインしてください

Username Password

peter@acmefinancial.net Peter123!@#
画面左上のナビゲーションバーを開き、ドロップダウンリストから Platform を選択してください
Auth Providers を開いてください
Edit をクリックし、ad-acmefinancial-net の設定を確認してください

Authentication Provider の設定を確認する

このセクションでは、”Authentication Provider Configuration”タブを確認します。関連する項目をクリックしてください

Configuration タブ

この項目は、基本的な authentication providerの設定を定義します。必要となるパラメータは以下です:

Attribute Description

Auth Provider Type Define the authentication provider being used

User Format Define if the user will login with username@domain (UPN) or domain/user (User Domain)

Note

release 3.15 では、Active DirectoryのみをAuth Providerとして選択することが可能です
Connection タブ

このセクションはDomain、URL、SSLの設定を行います

Note

SSL Parameters 配下に暗号化なしの接続を許可するためのオプションはありません

この例では、すでにADの証明書が適切に提供されている状態となります
User Binding タブ

この項目は、NGINX ControllerがActive Directoryに対し認証を行う際に必要となる “Bind” で用いるアカウントの情報を指定します
Group Setup タブ

この項目は、Role Based Access Controlに使用する Active Directory のグループのために利用する、キャッシュとQueryパラメータを指定します
Group Mappings タブ

この項目は、Active DirectoryのグループをNGINX Controller “内部(Internal)” で管理している “Roles Groups” への紐付けを指定します

コントローラの “Roles Groups” は Platform -> Roles 配下で設定できますより詳細な情報をご覧になる場合には、NGINX Controller ドキュメントの managing roles を参照してください

Group Mapping 設定で利用されているActive Directory Groupは以下の様にDomain Controllerで確認できます

Note

以下の画像は参考です。Domain Controllerへログインし確認する必要はありません

Note

あなたは “Peter Parker” としてログインしています。”Peter” は “nginx-controller-admins” のメンバーです。このActive Directoryのグループは、NGINX Controllerの “admin_group” に割り当てられています

追加情報

公開されているNGINX ControllerドキュメントはActive Directory authentication providerの詳細(detail)について記述しています

Lab 2 - NGINX Controller の冗長化

このラボのゴールはNGINX Controller clusterの3つ目のメンバーとしてホストを追加することです

本番環境では、我々のサービスに対し冗長性をもたせることが一般的です。複数のインスタンスを水平スケール・動作の管理を行うNGINX Controllerを用いた場合、単一の事象が様々な事象の引き金となることがあります。冗長構成の実装はコンプライアンスやルールの要素としても求められることがあります。この機能により複数のコントローラを用いて安定した環境を実現します

Important

想定時間: 15分

Note

このLabの手順はラボを実施する方がWindows jumphost – jumphost-1 から操作する手順を示しています。接続方法についてはこちらを参照ください。 F5 Labs - Index

追加するNGINX Controllerのノードを作成する

jumphostのChromeで開かれているNGINX Controllerの管理画面を操作します。証明書エラーが表示されている場合には適切に操作をして画面を開いてください
もし開かれていない場合、Chromeブラウザを開いてください
BookmarkからNGINX Controller UIにアクセスしてください
NGINX Controller のadmin accountである、Peter Parker でログインしてください

Username Password

peter@acmefinancial.net Peter123!@#
画面左上のナビゲーションバーを開き、ドロップダウンリストから Platform を選択してください
Cluster を開いてください
現在の “Cluster Configuration” を確認してください

Note

“Cluster Configuration” の項目は、クラスタを構成するNGINX Controllerインスタンスを示します。 FQDNはAPI Gateway podに割り当てる証明書で利用するcommon nameに該当します例: APIエンドポイントやGUIの接続先として公開するサービスの名称

Important

“load balancer”設定は今後リリースされるNGINX Controllerにて設定可能となる予定です追加の情報はラボの追加情報を参照してください

Note

“Nodes”として現在2つのNGINX Controller インスタンスが表示されています ( “controller-1” および “controller-2” に該当するノード)

画面右上の Create Node ボタンをクリックしてください
ダイアログに従って進め、”controller-3” インスタンスを追加するため、”Name” と “Hostname または IP Address” を指定してください。Save ボタンをクリックしてください

Field Value

Name controller-3

Hostname or IP 10.1.1.10
View にインストール手順が記載されています。インストールコマンドと “join key” をクリップボードにコピーしてください。

クラスタにインスタンスを追加するため install command を実行する

“controller-3” インスタンスにログインしてください。”PuTTY” を開き、保存済みのホストより controller-3 を選択し、Open をクリックしてください

Important

もし、Puttyがサーバのホスト鍵に関する警告を示した場合、接続のため Yes をクリックしてくださいこれは、ラボ環境の各ホストでユニークなhost keyを生成するため生じるものです
installerディレクトリより、install.sh コマンドを実行してください。そしてプロンプトの表示に対し “y” (“yes” の意味) を入力してください。

解凍するファイル名はディレクトリに保存しているものと一致している事を確認してください。異なる場合、適宜ファイル名を変更ください。

Important

こちらの操作はubuntuユーザで行います。ファイルはホームディレクトリ/home/ubuntuに配置しております
```
$ tar zxvf controller-installer-3.20.0.tar.gz
$ cd controller-installer/
$ ./install.sh --join-key {{base64 encoded key}}
```
コマンドの実行結果として、クラスタに追加が完了したことがノードに表示されます

View the results

Chromeを開き、Cluster の “Cluster Configuration” を確認してください

(Optional) Kubernetes Cluster の確認

もし、Kubernetes (k8s) について確認されたい場合、NGINX Controllerによって作成される k8s クラスタの情報を確認することが可能です

先程ログインした PuTTY の “controller-3” への接続を利用するか、新たにNGINX Controllerインスタンスのいずれか一つに接続してください

Important

もし、Puttyがサーバのホスト鍵に関する警告を示した場合、接続のため Yes をクリックしてくださいこれは、ラボ環境の各ホストでユニークなhost keyを生成するため生じるものです
クラスタノードを表示します
```
kubectl get nodes
```
Note

コマンドの出力結果として、k8s クラスタに3つのノードが存在することが確認できます
デプロイされたポッドを確認する
```
kubectl get pods -n nginx-controller -o wide
```
Note

コマンドの出力結果として、NGINX Controllerが複数のPodを3つのノードに対してデプロイしていることが確認できます (“NODE”カラムを確認ください)

追加情報

“load balancer”設定は今後リリースされるNGINX Controllerにて設定可能となる予定です追加の情報はラボの追加情報を参照してください

将来リリースされるNGINX Controllerでは、API Gateway Kubernetes serviceを公開するために利用するfloating self-ipが “load balancer” によって作成される予定です。オンプレミス環境ではL2 Failoverをサポートする MetalLB の構成、クラウド環境では k8sの type LoadBalancer を用いたクラウドネイティブな外部向けロードバランサー機能を利用する想定となります。

Lab 3 - NGINX Plus の追加

このラボのゴールは新たにNGINX Controllerの管理対象としてNGINX Plusを追加することです。 NGINX Controllerで管理する対象となるNGINX Plusは通常のNGINX Plus Subscriptionと異なる手順でライセンスキーの取得を行います。

Important

想定時間: 15分

Note

このLabの手順はラボを実施する方がWindows jumphost – jumphost-1 から操作する手順を示しています。接続方法についてはこちらを参照ください。 F5 Labs - Index

NGINX Plus のインストール

“nginxplus-4” インスタンスにログインしてください。”PuTTY” を開き、保存済みのホストより nginxplus-4 を選択し、Open をクリックしてください

Important

もし、Puttyがサーバのホスト鍵に関する警告を示した場合、接続のため Yes をクリックしてくださいこれは、ラボ環境の各ホストでユニークなhost keyを生成するため生じるものです

Curl コマンドを実行し、NGINX Controllerのログインに必要なCookie情報を取得します。ログインユーザとしてAdmin権限の Peter Parker でログインします

$ curl -k -c cookie.txt -X POST --url 'https://10.1.1.5/api/v1/platform/login' --header 'Content-Type: application/json' --data '{"credentials": {"type": "ACTIVE_DIRECTORY","providerName":"ad-acmefinancial-net", "username": "peter@acmefinancial.net","password": "Peter123!@#"}}'
$ curl -k -b cookie.txt -c cookie.txt -X GET --url 'https://10.1.1.5/api/v1/platform/login'

NGINX Plus インストールに利用する証明書と鍵を取得します

$ curl -k -b cookie.txt -c cookie.txt -X GET --url 'https://10.1.1.5/api/v1/platform/licenses/nginx-plus-licenses/controller-provided' --output nginx-plus-certs.tar.gz
$ tar zxvf nginx-plus-certs.tar.gz
$ ls nginx-repo.*

NGINX Plus インストールに必要となる手順を実施します。手順の各コマンドの役割は NGINX Plusのインストール手順(Ubuntu) を参照してください

$ sudo mkdir -p /etc/ssl/nginx
$ sudo cp nginx-repo.* /etc/ssl/nginx/
$ sudo wget https://cs.nginx.com/static/keys/nginx_signing.key && sudo apt-key add nginx_signing.key
$ sudo wget https://cs.nginx.com/static/keys/app-protect-security-updates.key && sudo apt-key add app-protect-security-updates.key
$ sudo apt-get install apt-transport-https lsb-release ca-certificates
$ printf "deb https://pkgs.nginx.com/plus/ubuntu `lsb_release -cs` nginx-plus\n" | sudo tee /etc/apt/sources.list.d/nginx-plus.list
$ printf "deb https://pkgs.nginx.com/app-protect/ubuntu `lsb_release -cs` nginx-plus\n" | sudo tee /etc/apt/sources.list.d/nginx-app-protect.list
$ printf "deb https://pkgs.nginx.com/app-protect-security-updates/ubuntu `lsb_release -cs` nginx-plus\n" | sudo tee -a /etc/apt/sources.list.d/nginx-app-protect.list
$ sudo wget -P /etc/apt/apt.conf.d https://cs.nginx.com/static/files/90pkgs-nginx
$ sudo apt-get update

NGINX Plus をインストールします。NGINX Controller に対応したVersionとしてR24をインストールします。NGINX Controllerに対応するNGINX PlusのVersionは Tech Spec を確認してください
```
$ sudo apt-get install nginx-plus=24-2~focal
$ nginx -v
```

NGINX PlusのインスタンスをNGINX Controllerに追加する

jumphostのChromeで開かれているNGINX Controllerの管理画面を操作します。証明書エラーが表示されている場合には適切に操作をして画面を開いてください
もし開かれていない場合、Chromeブラウザを開いてください
BookmarkからNGINX Controller UIにアクセスしてください
NGINX Controller のadmin accountである、Peter Parker でログインしてください

Username Password

peter@acmefinancial.net Peter123!@#
画面左上のナビゲーションバーを開き、ドロップダウンリストから Infrastructure を選択してください
画面右上の Create ボタンをクリックしてください
Add an existing instance を選択し、”nginxplus-4” インスタンスを追加するため、項目に以下の内容を指定してください

Field Value

Name nginxplus-4

Location West Coast Data Center (OTHER_LOCATION)

Allow insecure server connections to NGINX Controller using TLS Enable(Check)
Instructions に表示されるCURLコマンドの内容をコピーしてください。次のステップで利用します。コピーが完了しましたら Close をクリックして画面を閉じてください
前の手順で利用した “nginxplus-4” のターミナル、または “PuTTY” を起動し再度 nginxplus-4 を開いてください。Instructions からコピーしたcurlコマンドを実行してください。コマンドを実行するとプロンプトで実行を進めて良いか確認するプロンプトが複数回表示されます。内容を確認して y を入力してください。以下の内容が表示されれば正常に完了です
ChromeでNGINX Controllerの Infrastructure を開き、新たに “nginxplus-4” が追加されていることを確認してください。その他ステータスが正しく閲覧できることを確認してください
表示名(Display Name)などを変更する場合は対象インスタンスをクリックし、 Edit をクリックしてください

(Optional) NGINX Controllerの管理対象となるNGINX Plusの設定

NGINX PlusをNGINX Controllerの管理対象として追加した際に、以下のような変更が行われます。参考情報としてご確認ください。

NGINX Plusに対しNGINX Controller Agentが正しくインストールできた場合、以下のようにモジュールが配置されます

$ ls /etc/nginx/modules
ngx_http_f5_metrics_module-debug.so
ngx_stream_f5_metrics_module-debug.so
ngx_http_f5_metrics_module.so
ngx_stream_f5_metrics_module.so

管理対象となるNGINX Plusの設定は、NGINX Controllerのみが変更可能となります。
module2 で案内する手順により対象のNGINX Plusに対し設定を反映する際に、様々な管理用設定も含まれた設定ファイルが生成されます
以下がその設定内容となります

$ less /etc/nginx/nginx.conf
# Generated by NGINX Controller 1639124265 [ADC-a018e23e-770d-4b80-9a5d-9956cedb7738] - instance:nginxplus-4:west;
※省略※

load_module modules/ngx_http_f5_metrics_module.so;
load_module modules/ngx_stream_f5_metrics_module.so;

http {
      f5_metrics on;
      f5_metrics_server unix:/tmp/avr-socket.sr;

※省略※

      log_format controller_recommended_log_format '$remote_addr - "$remote_user" [$time_local] "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent" "$http_x_forwarded_for" "$host" sn="$server_name" rt="$request_time" ua="$upstream_addr" us="$upstream_status" ut="$upstream_response_time" ul="$upstream_response_length" cs="$upstream_cache_status" pa="$f5_published_api"';
      access_log /var/log/nginx/access.log controller_recommended_log_format;
      error_log /var/log/nginx/error.log;

※省略※

      server {
               server_name 127.0.0.1;
               listen 127.0.0.1:49151;
               access_log off;
               f5_metrics off;
               location /api {
                        api;
               }
      }
}

stream {
      f5_metrics on;
      f5_metrics_server unix:/tmp/avr-socket.sr;
}

Module 2 - ADC Application Workflows

NGINX Controllerの主なユースケースの一つが、ADCサービスをモダンアプリケーション環境に提供することです。このセクションでは、NGINX Controllerの「app-centric(アプリケーション中心)」で利用されるコンセプトについて紹介します。

Lab 1: NGINX Controller GUIでアプリケーションのデプロイを確認します
Lab 2: お客様環境でどの様にNGINX ControllerのアプリケーションデプロイをCI/CD Piplineに統合するか確認するため、postmanを用いたアプリケーションのデプロイを確認します
Lab 3: 様々なADCのadvanced機能をデプロイ、テストします。URI rewrite、HTTP Header操作などの機能を確認します
Lab 4: TCP proxy / Load Balancerの設定します
Lab 5: 特定のIPアドレスで待ち受けるGatewayの設定、及び関連するコンポーネントの設定を行います
Lab 6: Module 3、4 の準備として、セキュリティイベントに関連するトラフィックを実行します

Lab 1 - GUIで ADC App の作成

このラボのゴールはラボを実施する方がADCに関するNGINX Controllerのオブジェクトモデルやコンセプトを理解いただくことです。

NGINX Controllerを用いた「app-centric(アプリケーション中心)」のモデルは、いわゆる旧来のLBで実施していた「network-centric(ネットワーク中心)」モデルとは別のデザインであり、NGINXの設定・構成をベースにしたデザインとなります

Important

想定時間: 15分

Note

このLabの手順はラボを実施する方がWindows jumphost – jumphost-1 から操作する手順を示しています。接続方法についてはこちらを参照ください。 F5 Labs - Index

NGINX Controller が持つオブジェクトのコンセプト

このセクションではNGINX Controllerのオブジェクトについて説明します。BIG_IPやNGINXのコンセプトや記述方法と比較してください

Environments

“Environment”は論理的なAppのグループです。これはRBAC(Role Based Access Control)の最上位の構成要素として利用されます Environmentsは組織や構成管理の観点で利用されるものであり、実際に管理対象となるNGINX Plusインスタンスにデプロイされるコンフィグ上には表現されません。概念的には、BIG-IPのパーティションに似たものとなります。

Cert

SSL証明書と鍵をNGINX Controllerで一元的に管理・保存します。これらは”Gateway”の機能に割り当てることが可能であり、設定に応じて利用します。

Gateway

“Gateway”は対象となるNGINX PlusインスタンスにデプロイするNGINX Config / Directiveに相当しますこの機能では、待ち受けるFQDN、許可するHTTPメソッド、SSL/TLS設定、その他様々なHTTP Parameter(buffer , body size , TCP keepalive)が含まれます。これらの設定は、対象となるNGINX Configの”server” directive配下に表記される情報となります。 BIG-IPのTCP / HTTP / ClientSSL Profile等に相当する設定です

App

“App”はマイクロサービス環境で動作する すべての アプリケーションの要素を論理的にまとめたグループです。 “App”に含まれるそれぞれの”Component”が各マイクロサービスを示します。これらは論理的なグループを示しており、NGINX Plusインスタンスの設定情報を示すものではありません。 BIG-IPファミリのコンセプトでは、AS3のテナントや、BIG-IQの”Application”に相当します。

Component

“Component”は単一のサービスを示す最も基本的な表現です。これは通信を待ち受けるためのURIなどの情報を含み、分散先サーバである”Workload Group”等を管理し、トラフィックの転送先、HTTPの操作に関する情報(redirect, rewrite, header 操作)、ロギング設定などを指定します BIG-IPのVS、Poolや、HTTP Profile、Local Traffic PolicyやiRuleの一部の機能に該当します

Workload Group

“Workload Group”はバックエンドサーバをまとめたグループです。NGINX Configでは”upstream”でこの内容を記述します。 BIG-IPの”pool”および個々の”pool member”に相当します

Applicationをデプロイする

jumphostのChromeで開かれているNGINX Controllerの管理画面を操作します。証明書エラーが表示されている場合には適切に操作をして画面を開いてください
もし開かれていない場合、Chromeブラウザを開いてください
BookmarkからNGINX Controller UIにアクセスしてください
NGINX Controller のadmin accountである、Peter Parker でログインしてください

Username Password

peter@acmefinancial.net Peter123!@#
Services を開いてください。このセクションおよび配下の項目がこのラボで必要となる設定を作成するために利用します

Environmentを作成する

“Environments” を選択してください.
右上にある “Create” ボタンをクリックしてください
以下の通り項目を埋めてください

Field Value

Name echo

Display Name Echo Environment
Submit をクリックし、操作を完了させてください

証明書の追加

“Certs” を選択してください
右上にある “Create” ボタンをクリックしてください
以下の通り項目を埋め、適切な Environment をドロップダウンリストから選択してください

Field Value

Name echoapp.net

Environment Echo Environment
Import PEM or PKC12 ラジオボタンを選択し、Browse から証明書と鍵を選択します

証明書 (echoapp.net.crt) 鍵 (echoapp.net.key) をポップアップで表示される内容から選択してください ( This PC -> Documents -> Certs )

Note

証明書と鍵はそれぞれアップロードをしてください。NGINX Controllerは複数のファイルアップロードに対応していません
Submit をクリックし、操作を完了させてください

Gatewayの作成

“Gateways” を選択してください
右上にある “Create” ボタンをクリックしてください
Configuration セクションの内容を以下の通り項目を埋めてください。入力後、Next をクリックするか、次のセクションの名称をクリックしてください

Field Value

Name echoappgw

Environment Echo Environment
Placements セクション配下のInstance Ref で “Development NGINX West 03 (CAS)” を選択してください
Hostnames セクション配下で、指定のホスト名を追加してください(http://echoapp.net, https://echoapp.net). それぞれのホスト名で、 Match Method は指定しないでください。”Cert Reference”で echoapp.net を選択してください。ホスト名の追加操作が完了した場合、正しくそれぞれのメニュー右下部の”Done”をクリックしてください

Note

You will need to use the Add Hostname link pictured below to add multiple hostnames.
Submit をクリックし、操作を完了させてください

Appを作成する

“Apps” を選択してください
右上にある “Create” ボタンをクリックしてください
以下の通り項目を埋め、ドロップダウンリストから Environment を選択してください

Field Value

Name echoapp

Environment Echo Environment
Submit をクリックし、操作を完了させてください

Componentを作成する

“Components” セクションを選択し、画面中央の “Create Component” をクリックしてください
以下の通り項目を埋め、ドロップダウンリストから Gateway Refs を選択してください

Field Value

Name echoappcomponent

Gateway Refs echoappgw
URIs のセクションを開き、URIに / を指定します。Match Method は指定しないでください/
Workload Groups のセクションを開き、以下の通り項目を埋めてください。Backend URIの指定、Workload Group双方の操作が完了した場合、正しくメニュー右下部の”Done”をクリックしてください

Field Value

Name Echo Backend

Backend Workload URIs http://10.1.20.11:8000
Submit をクリックし、操作を完了させてください

Echo Applicationのテスト

jumphost-1 のクロームで新しいタブを開き、”Developer Tools”を有効にしてください
先程の手順で作成したURLに対し (http://echoapp.net and https://echoapp.net) ブラウザからアクセスし、Echo Applicationが機能していることを確認してください。結果の確認のため echoapp.net をURLに入力いただくことで、結果の確認が可能です

Note

これはHTTP Requestの情報を返す、シンプルなWebアプリケーションです

Lab 2 - ADC App 作成のプログラマビリティの確認

このラボのゴールはNGINX Controller APIを用いたApp Componentの作成です。

このラボはお客様環境で自動化ツールやCI/CD Pipelineで実施するプログラムによるデプロイのProxyとしてPostmanを利用します。

Important

想定時間: 5分

Note

このLabの手順はラボを実施する方がWindows jumphost – jumphost-1 から操作する手順を示しています。接続方法についてはこちらを参照ください。 F5 Labs - Index

Trading App の現在の状況を確認

Chromeで、http://trading.acmefinancial.net を開き、 Login ボタンをクリックしてください。これは、”trading” アプリケーションの例となります
以下の認証情報を用いてアプリケーションにログインしてください

Username Password

matt ilovef5

Note

右側のフレームに表示されている “Quick Money Transfer” が “Coming Soon” であることを確認してください

Postmanを利用して Component のデプロイ

Jumphostで Postman が起動していない場合、デスクトップのアイコンクリックしアプリケーションを開いてください。 NGINX Controller 3.x Collection を開いてください
Common Tasks、 Admin Logon を開き、 Login to Controller – admin – local をクリックしてください
Postmanの Send を選択してください

Note

NGINX Controllerが “204 No Content” と認証Cookie情報を応答します PostmanはこのCookieを以降のサブリクエストの認証情報として利用します (以下の例は、次の操作でRequest欄「・・・」＞Cookies＞MANAGE COOKIESよりsession欄を開いた結果です)
Retail-Development Environment, Application - trading フォルダを開きます。 Application trading サブフォルダを開き、リクエスト名 4) Create Component – transfers を選択してください
Postmanのリクエストエリアにある Body をクリックしてください。PUT リクエストのペイロードを確認してください。 JSONの desiredState, logging, security, backend 配下のプロパティ値は前回のラボでデプロイした Component に関する内容であることが確認できます
Postmanで Send を選択

Note

NGINX Controllerは “eventual consistency model” に従います。APIはPostmanのリクエストに “202 Accepted” ステータスコードを返します。 NGINX Controllerは現状動作し、意図した状態であることが確認できます

Trading App の変更を確認する

Chromeで、http://trading.acmefinancial.net/trading/index.php を再度開きます。 ”Quick Money Transfer” が”Comming Soon”からActiveに変わっていることを確認できます

Lab 3 - ADC によるより詳細なトラフィック制御機能(Programmability)

このラボのゴールは、現在NGINX Controllerで利用可能な “advanced ADC” 機能を確認します。以前、これらの機能はNGINX Controllerで対応できず、NGINX Insntanceを個別に設定した場合の設定のみで利用が可能だった内容です

Important

想定時間: 10分

Note

このLabの手順はラボを実施する方がWindows jumphost – jumphost-1 から操作する手順を示しています。接続方法についてはこちらを参照ください。 F5 Labs - Index

App Componentを開く

Chromeを開く
ブックマークよりNGINX Controller のGUIにアクセス
NGINX Controller のadmin accountである、Peter Parker でログインしてください

Username Password

peter@acmefinancial.net Peter123!@#
Services を開いてください
“Apps” を選択してください
“Echo Environment”から Module 2 Lab 1 で作成した echoapp を選択してください

URI Rewriteを設定する

Components を開いてください。以前作成した “echoappcomponent” を Edit を開いてください
“Advanced” セクション内の、 Programmability を選択してください
Chrome内で、Componentによる構成変更前に、”echo” アプリケーションからどのような応答があるか確認してくださいこのモジュールの前の項目で実施したように Chrome Developer tools を開き、http://echoapp.net/example へアクセスし、結果を確認してください

Note

The app’s JSON response confirms that the request received was to path: "/example".

NGINX Controllerで、”URI Rewrite”をコンポーネントに追加してください。これはシームレスにすべての “/example*” 宛のリクエストを “/modified*” へ変更します “Programmability” ダイアログの Add URI Rewrites をクリックしてください

http://echoapp.net/example

操作を完了し、変更内容を反映するため、Done をクリックしてください。 NGINXの別に rewrite モジュールがあり、PCRE正規表現の記述を用いて、NGINX Controllerの設定変更を行います

Field Value

Incoming Pattern ~*^/example(.*)$

Rewrite Pattern /modified$1

Important

より詳細な順序を指定したURIを操作するルールセットが必要となる場合、 “After Execute” 機能を利用し実装を検討ください
Submit をクリックし、変更したComponentの内容を “Gateway” にプッシュしてください。コンポーネントのステータスが、”Configuring” から “Configured” に変わったことを確認してください
Chromeで、echoapp に対し “/example” というリクエストを送信し、Rewrite動作のテストをしてください。応答データの内容を確認してください

Note

“Echo” appのJSONレスポンスは、ブラウザのURIで入力した情報(“/example”)ではなく、”/modified(変更後)”のリクエストが表示されていることを確認ください

Request Header 変更機能を設定する

NGINX Controllerの “echoapp” App の画面を再度開き、Components を開いてください。先程作成した “echoappcomponent” で Edit をクリックしてください
“Advanced” セクション配下にある Programmability を選択してください
Chromeで、前回 “echo” app にアクセスした際のレスポンスヘッダーの情報を確認してください
NGINX Controllerで、コンポーネントの”Request Header Modification”を追加してください。この機能はupstream/pool memberに通信を転送する際に、ADCとして動作するNGINX PlusでHTTP Headerを追加する機能です “Programmability” の Add Request Header Modification をクリックしてください
以下の内容を入力し、内容を保存するため Done クリックしてください

Field Value

Action Add

Header Name X-Controller-Instance

Header Value Development NGINX West 03 (CAS)
Submit をクリックし、変更したComponentの内容を “Gateway” にプッシュしてください。コンポーネントのステータスが、”Configuring” から “Configured” に変わったことを確認してください
Chromeで、echoapp に対し再度リクエストを送信し(更新ボタンをクリックするなど)HTTP Headerの挿入について動作を確認してください。応答データの内容を確認してください

Note

“echo” Appが応答するJSONデータは、HTTPリクエストに追加されたヘッダーの情報が表示されます。このヘッダー追加機能により、どのNGINX Plusインスタンスが通信の操作を行ったか示すHTTP Headerの追加をすることが可能ですリクエストやレスポンスのHTTP Headerを追加・削除するなど、アプリケーションに求められる内容を実施することが可能です

追加情報

“Programmability” セクションでは、URIリダイレクト、URI Rewrite、リクエストヘッダー操作、レスポンスヘッダー操作を行うことができますこれらの機能は、NGINXの`rewrite`_モジュールによって実現しています。より詳細な情報についてはmoduleのドキュメントを参照してください

NGINX REGEX validator は作成した正規表現を確認するのに便利です。こちらの記事を参照ください(regex blog)。また、NGINXが使うPerlの正規表現(PCRE)も理解に役立ちます。合わせてご確認ください

Lab 4 - TCP Load Balancing / Routing

このラボのゴールは、L4 / TCPロードバランサを設定することです。すべてのトラフィックがHTTPではなく、HTTPトラフィックを操作する方法は多くありますが、ときにはTCP/UDPトラフィックの操作をしなければいけません

Important

想定時間: 5分

Note

このLabの手順はラボを実施する方がWindows jumphost – jumphost-1 から操作する手順を示しています。接続方法についてはこちらを参照ください。 F5 Labs - Index

App Componentを開く

Chromeを開きます
BookmarkからNGINX ControllerのGUIを開きます
NGINX Controller のadmin accountである、Peter Parker でログインしてください

Username Password

peter@acmefinancial.net Peter123!@#
Services セクションを開いてください
“Apps” を選択してください
“Echo Environment”から Module 2 Lab 1 で作成した echoapp を選択してください

TCP Component を作成する

echoapp を利用します: 右上の “Create Component” をクリックし、”Components” セクションを選択してください
各項目を埋め、ドロップダウンリストから Gateway Refs を適切に選択してください

Field Value

Component Type TCP/UDP

Name echoapptcp

Gateway Refs echoappgw
URIs ダイアログを開き、URI tcp://*:9443 を追加してください
Workload Groups ダイアログを開、各項目を埋めてください

Field Value

Name TCP Backend

Backend Workload URIs tcp://10.1.20.21:8000

Backend Workload URIs tcp://10.1.20.11:8000
操作を完了するため Submit をクリックしてください

TCP Componentをテストします

jumphost-1 のChromeで新しいタブを開き、 “Developer Tools” を有効にしてください
先程新たに作成したURL(http://echoapp.net:9443 )を開き、TCP設定で “echo” アプリケーションがどのように動作しているか確認してください echoapp.net にアクセスしたリクエストを選択し、表示結果を確認してください

Note

これはHTTP Requestの情報を返す、シンプルなWebアプリケーションです
同じURLのHTTPSページ(https://echoapp.net:9443 )を開き、TCP設定で “echo” アプリケーションがどのように動作しているか確認してください閲覧の結果、トラフィックはブロックされますもし、TCPトラフィックを暗号化したい場合、証明書を設定し、URLを指定する項目で tcp とした項目を tcp+tls とすることで、バックエンド転送前にゲートウェイでHTTPSトラフィックのSSL Offloadを実現することが可能です

追加情報

“TCP/UDP” コンポーネントは、L4 / Stream Proxyを提供します。これらの機能は NGINXの stream モジュールを利用しています。詳細についてはドキュメントを参照してください

Lab 5 - 待ち受ける特定のアドレスを定義する

このラボのゴールはGatewayで待ち受ける特定のIPアドレスの設定について理解することです。 NGINXインスタンスの特定のIPアドレスを使い制御することが望ましい場合が多々あります。これはデータプレーンの冗長化や、NGINX plusインスタンスのIPアドレスを通じてトラフィックの管理をする際に有用です

Important

想定時間: 5分

Note

このLabの手順はラボを実施する方がWindows jumphost – jumphost-1 から操作する手順を示しています。接続方法についてはこちらを参照ください。 F5 Labs - Index

Gatewayの待ち受けるIPアドレスを定義する

jumphostのChromeで開かれているNGINX Controllerの管理画面を操作します。証明書エラーが表示されている場合には適切に操作をして画面を開いてください
もし開かれていない場合、Chromeブラウザを開いてください
BookmarkからNGINX Controller UIにアクセスしてください
NGINX Controller のadmin accountである、Peter Parker でログインしてください

Username Password

peter@acmefinancial.net Peter123!@#
Services セクションを開き、このラボではこちらのセキュションの項目を対象として設定を行います

Gatewayを作成する

“Gateways” を選択します
右上の “Create” ボタンをクリックします
Configuration に表示される項目に以下の内容を入力します。終了後 Next をクリックするか、次の項目名をクリックしてください

Field Value

Name specialapp

Environment Echo Environment
Placements で、Development NGINX West 03 (CAS) を対象インスタンスとして選択します
Placements で、10.1.20.213 を待ち受けIPアドレスとして入力して下さい

Note

これは “Development NGINX West 03 (CAS)” に予め設定されたSecondary IPアドレスです。この情報はNGINX Controller Infrastructure セクションのインスタンスの情報から確認いただけます
Hostnames の Hostname は空白としてください。これは、あなたが後にコンポーネントのURI設定でホスト名を指定すること、TCP や UDPのコンポーネントとしてIPアドレスに着信するすべてのトラフィックを扱うことを意図します
Click Submit to complete.

Component を作成する

echoapp を利用します: 右上の “Create Component” ボタンをクリックし、”Components” セクションを開きます
項目に以下の内容を入力し、ドロップダウンリストより Gateway Refs の内容を選択してください

Field Value

Name wildcard

Gateway Refs specialapp
URIs で、URI http://.*:8080 を追加し、REGEX を Match Method として選択してください

Note

URIのPortが8080として定義されない場合、ListenIP 10.1.20.213 on Port 80 conflicts with an existing gateway とエラーが出力されます同一のNGINX PlusインスタンスHTTP(port 80)やHTTPS(port 443)トラフィックを処理する別のGateway設定があり、設定したポートが唯一のポートでない場合にメッセージが出力されます。もしListen IPが定義されない場合、すべてのIPアドレスがGatewayで利用されます
Workload Groups で、以下の通り項目を埋めてください

Field Value

Name wildcard Backend

Backend Workload URIs http://10.1.20.21:8001
作業を完了させるため Submit をクリックしてください

Listen IP Component をテストする

jumphost-1 のChromeで新しいタブを開き、 “Developer Tools” を有効にしてください
先ほど作成したURI(http://10.1.20.213:8080)に接続し、specialapp GatewayでIPアドレスで待ち受けるよう設定した機能の動作を確認してください

Note

.* の正規表現はURIに指定されたすべてのホスト名や、IPアドレスに該当することを示すルールとなります

Lab 6 - Security トラフィックジェネレータを実行する

このラボのゴールはセキュリティ機能が有効となったデータパスに対し、トラフィックジェネレータを実行することです

Note

このラボの内容は少なく、動作環境の主な確認は次のラボで実施しますただし、今後のラボで必要となる作業のため必ず完了してください

Important

想定時間: 5分

Note

このLabの手順はラボを実施する方がWindows jumphost – jumphost-1 から操作する手順を示しています。接続方法についてはこちらを参照ください。 F5 Labs - Index

Analytics に利用する WAF Traffic Generation の実行

Important

このステップは Module3 のAnalytics / 統計情報の確認のため必須の内容となります

“loadgen-1” インスタンスにログインしてください。”PuTTY”でsaved sessionに表示される loadgen-1 を選択し Open をクリックしてください

Important

もし、Puttyがサーバのホスト鍵に関する警告を示した場合、接続のため Yes をクリックしてくださいこれは、ラボ環境の各ホストでユニークなhost keyを生成するため生じるものです
以下の “docker” commandでラボでデプロイされたでもアプリケーションに対しトラフィックを生成してください
```
$ sudo docker start wrk_trading.acmefinancial.net-cas
```
コマンドの実行が完了するとコンテナ名が出力されます(“wrk_trading.acmefinancial.net-cas”).

Module 3 - Analytics

このセクションでは、NGINX ControllerのAnalytics機能をNetOps , DevOps の Personaでどの様に利用するか確認します

Lab 1：NGINX Controllerが提供するNGINX Plus instanceの統計情報を確認します

Lab 2：Controller App Security (CAS)ライセンスが有効な場合に、AppやWAFの分析情報について確認します

Important

Module 2 Lab 6 (Analytics に利用する WAF Traffic Generation の実行) のLoad Genratorについて確認してください。このLabにより、統計情報を確認することが可能となります

Lab 1 - NetOps/Admin向けAnalytics

このラボのゴールはNGINX Controllerが提供するNGINX Plus instanceの統計状況を確認することです。このAnalyticsのカテゴリは主にNetOpsの担当者向けとなります

Important

想定時間: 5分

Note

このLabの手順はラボを実施する方がWindows jumphost – jumphost-1 から操作する手順を示しています。接続方法についてはこちらを参照ください。 F5 Labs - Index

Dashboard概要

jumphostのChromeで開かれているNGINX Controllerの管理画面を操作します。証明書エラーが表示されている場合には適切に操作をして画面を開いてください
もし開かれていない場合、Chromeブラウザを開いてください
BookmarkからNGINX Controller UIにアクセスしてください
NGINX Controller のadmin accountである、Peter Parker でログインしてください

Username Password

peter@acmefinancial.net Peter123!@#
ログイン後、Dashboardの”Overview”が表示されます。”System Metrics”セクションは、”Ovewview”の最上部に配置され、NetOps運用者が簡単に状態を把握することが可能となってます

Instance Analytics

画面左上のNavigation Barを選択し、表示されるドロップダウンリストから Infrastructure を選択してください
表示されるインスタンスのリストから、Production NGINX East 01 をクリックしてくださいこの画面は “Instance Overview” ページです。Bytes In、Bytes Out、CPU Usage、Memory Usage 等のメニューを選択し画面を切り替えてください

このセクションは選択したインスタンスの状態をシングルペインで簡単に確認することが可能です適切な時間でインスタンスのパフォーマンスがどの様になっているか確認するため、Time Rangeをドロップダウンリストから切り替えてください

Important

このラボの対象外となりますが、Analytics -> Dashboards も合わせてご確認ください NGINX Controllerによって集積される数百を超えるインスタンス・アプリケーションのメトリクスをDashboard elementとして表示することが可能です

Lab 2 - DevOps/Developer向けAnalytics

このラボのゴールは Controller App Security (CAS)のライセンスが有効な場合に、NGINX Controllerが提供するアプリケーションやWAFの分析結果を確認することです。このAnalyticsのカテゴリは主に個々のアプリケーションやコンポーネントを管理するDevOps、開発の担当者向けとなります

Important

想定時間: 5分

Note

このLabの手順はラボを実施する方がWindows jumphost – jumphost-1 から操作する手順を示しています。接続方法についてはこちらを参照ください。 F5 Labs - Index

Dashboard概要

jumphostのChromeで開かれているNGINX Controllerの管理画面を操作します。証明書エラーが表示されている場合には適切に操作をして画面を開いてください
もし開かれていない場合、Chromeブラウザを開いてください
BookmarkからNGINX Controller UIにアクセスしてください
NGINX Controller の特権を持たないuser accountである、Natasha Romanoff でログインしてください

Username Password

natasha@acmefinancial.net Natasha123!@#
Nログイン後、Dashboardの”Overview”が表示されます。 “Application Metrics”のセクションは標準でDashboardに含まれる項目であり、DevOps、開発の担当者が簡単に状態を把握することが可能となってます

Critical Analytics

画面左上のNavigation Barを選択し、表示されるドロップダウンリストから Infrastructure を選択してください
表示されるインスタンスのリストから、Production NGINX East 03 (CAS) をクリックしてくださいインフラチームにより、NGINX App Protect (WAF) のモジュールを有効にしたNGINX Plus Insntanceが設定されています

Note

NGINX Controller insntaceはこのラボで”Controller Application Security (CAS)”を利用しています
画面左上のNavigation Barを選択し、表示されるドロップダウンリストから Services を開きます

Apps を選択してください
Trading Application (CAS) appを開いてください。”Analytics” セクションは”App”に含まれるすべての”Components”のデータをここに表示します
このラボでは、”Component”のレベルまでAnalyticsのデータをドリルダウンしたいと思います。 Components セクションを選択します。DevOps、開発の担当者が管理するAppに対し、WAFポリシーを有効・向こうにする権限があることを確認してください (“Natasha”でログインしたことを思い出してください)

Note

NGINX Controllerは設定したappに対し、self-serviceでWAFの有効・無効機能を提供しています
Trading Main Component をクリックし、Critical Analytics を左のナビゲーションから選択してください。右上の Breakout By のドロップダウンリストから Request Outcome Reason を選択してください。画面を下部へスクロールし、”HTTP Requests (SUM)” のグラフを確認ください

Note

CAS が有効でない場合、このグラフは”すべて”のリクエストを含むのみとなります。次のモジュールでは、CASの機能を確認します

Module 4 - Application Security

このセクションでは、NGINX Controller Application Securityについて確認します。これはNGINX App Protectエンジンを利用した、NGINX ConrollerのAdd On Moduleです

Lab 1: ポリシーが適用されたアプリケーションに関連するイベントやメトリクスを確認し、NGINX Controller Application Security Moduleを確認します

Lab 2: NGINX Controller Application Security ModuleをAPIを通じて操作することを確認します

Important

Module 2 Lab 6 (Analytics に利用する WAF Traffic Generation の実行)のロードジェネレータを実行したことを確認してください。このラボでAnalyticsの結果として参照します

Lab 1 - Application Security (GUI)

このラボのゴールは、ポリシーが適用されたアプリケーションに関連するイベントやメトリクスを確認し、NGINX Controller Application Security Moduleを理解することです

Important

想定時間: 15分

Note

このLabの手順はラボを実施する方がWindows jumphost – jumphost-1 から操作する手順を示しています。接続方法についてはこちらを参照ください。 F5 Labs - Index

Component の Security を有効にする

Chromeを開きます
BookmarkからNGINX Controller UIにアクセスしてください
NGINX Controllerの特権を持たないユーザである Natasha Romanoff でログインしてください

Username	Password
natasha@acmefinancial.net	`Natasha123!@#`

Services メニューを開きます
Apps を選択します
“Trading Application (CAS)” app を開いてください
Overview にはAppのすべてのコンポーネントから集約されたデータやグラフが表示されます
このラボでは、コンポーネントでWAFが有効になっていることを確認します。 Components セクションを選択し、Trading Main Component をクリックします
Edit Component ボタンをクリックします
Security リンクをクリックします。このコンポーネントですでにWAFが有効になっていることが確認できます。トグルボタンにチェックマークが表示されています。アプリケーションを管理する DevOps / 開発者がWAFの有効・無効を制御することができることを確認してください。

(“Natasha”でログインしたことを思い出してください)

Note

NGINX Controllerは設定したappに対し、self-serviceでWAFの有効・無効機能を提供しています

Note

Retail Development environmentでWAFを有効にしたことにより、Acme Financial corporationにおけるリスクを最小化することができています。これは、コンポーネントの Monitor Only がオフになっていることが示しています

Security Analytics を確認する

“Trading Application (CAS)” appで、Components セクションを選択し、Trading Main Component をクリックしてください
Security Analytics リンクをクリックします。ここで選択したコンポーネントに関するセキュリティに関する統計情報などが表示されます
ドロップダウンリストから Last 30 minutes を選択します。WAF Suspicious vs Normal Traffic まで画面をスクロールします。トラフィックジェネレータがこのコンポーネントに対し動作した事により、グラフが表示されていることが確認できます。これはオペレータが指定した時間間隔の中で悪意あるトラフィックの急激な増加を直ちに知ることができます。以前の時間と比較しし、セキュリティイベントの急激な変化ないか確認してください(Prev Day がデフォルトで選択されています) 次のステップで利用するため、グラフの急激な増加が見られた地点にマウスを置き、その発生時間をメモしてください
“Top URIs Targeted” list” まで画面をスクロールしてください。このリストは攻撃の対象となったURIを多いものから表示します。右のドロップダウンに表示されるオプションからフィルタリング機能を利用することが可能です
“WAF Top Threats” リストを確認するため、画面をスクロールしてください。このリストは、Attack Types (default selection)や、Signatures を元にした脅威をリストにしたものです右のドロップダウンに表示されるオプションからフィルタリング機能を利用することが可能です

Note

イベントデータの量に依存して、”WAF Top Threats” リストの表示に時間がかかる場合があります

Note

WAFをMonitor Only Modeでデプロイした場合にも、Analytics やイベントのデータは潜在的な攻撃を判断するために有用です。また、これらのデータをSplunkやDatadogに送付することが可能です

Security Events を確認する

Security Events をクリックしてください。ここはセキュリティイベントが記録されており、リクエストの詳細などが確認できます
対象となる日時を選択し、グラフを確認します。Last 24 hours と現在表示されているドロップダウンリストをクリックし、Last 5 minutes を選択します
より詳細なセキュリティの情報を確認するため、特定の行をクリックします。画面右側にイベントの詳細が表示されます
THREAT ORIGIN セクションで詳細を確認するため画面をスクロールし、Remote Address のフィールドを確認してください。マウスカーソルをこの項目に合わせ、funnel アイコンをクリックしてください。この操作により、フィルタを作成します。この操作により、”Security Events” リストを “remote address” でフィルタしました

Note

Notice that many “Event Details” data points can be used as filters. This powerful filtering feature allows for quick pattern detection.
現在特定のIPアドレスでフィルタされたセキュリティイベントリストが表示されています。フィルタされたリストから、アクセスもととなるユーザは妥当なユーザであるかどうか確認してください
Security Analytics リンクをクリックしてください。イベントに関連する Signature ID を確認するため、WAF Tuning リンクをクリックしてください。
ID 200013018 のSignatureをクリックしてください。高いパーセンテージを示すViolationとして表示されています。これはリクエストに対する意図しないブロックでしょうか？”False Positive(誤検知)”が発生している可能性もあります
View Events ボタンをクリックし、このリクエストが誤検知であるかどうか確認するためリクエストの情報を確認します
前のステップで、Attack Signatureでフィルタされたセキュリティイベントのリストが表示されています。拒否されたリクエストの一つをクリックし、右に表示される詳細を確認してください
拒否の詳細を確認するため THREAT TARGET セクションを確認してください。以下の Request Detail でハイライトされた部分を確認してください。これは実際にWAFが拒否したGETリクエストです:
クロームで新しいタプを開き、開発者ツールを有効にした状態でアプリケーションにアクセスしてください URLは http://trading.acmefinancial.net/wp-admin/admin-post.php?do_reset_wordpress です。このリクエストでユーザにどの様に見えるか、動作を確認してください。何が見えましたでしょうか？レスポンスに “Support ID” が確認できます。これはセキュリティログの詳細にも記録されるこのイベントを示すIDです
このラボではリクエストが誤検知であると想定して確認を進めました。NGINX Controllerの管理画面で、次のセクションで利用するため、Signature IDをイベントの詳細からコピーしてください

_images/TradingMainCASComponentEventsCopy.png

WAF policy のチューニング

コンポーネントのSecurity Configurationを変更するため、Edit Config をクリックしてください
Security をクリックし、signature ID 200013018 を “Disable Signatures” テキストボックスに貼り付けてください
コンポーネントのセキュリティポリシーを更新するため Submit をクリックしてください

Note

WAF コンポーネントの設定が完了すると、以下のように見えます:

少なくとも30秒間の間を開け、再度ブラウザでの接続を試してください。現在はリクエストが許可されることを確認してください(出力は 404エラーですがWAFによる制御は行われない状態となっています).

Lab 2 - Application Security (API)

このラボのゴールは、NGINX Controller Application Security ModuleをAPIを通じて操作することです

Important

想定時間: 5分

Note

このLabの手順はラボを実施する方がWindows jumphost – jumphost-1 から操作する手順を示しています。接続方法についてはこちらを参照ください。 F5 Labs - Index

Alter Security Settings in API

あなたはNGINX ControllerのREST APIを通じてWAFを有効にしたり設定を変更したりする方法がわかりますか？これを達成するのが、PostmanやRed Hat Ansibleなど構成管理ツールを用いた自動化です。このラボでは、PostmanをWindows jumphostから操作し動作を確認します

Postmanを用いて、Component の Security Settings を更新する

jumphostで Postman を開きます。NGINX Controller 3.x Collection を開きます
Common Tasks、 User Logon を開き Login to Controller – Natasha Romanoff - AD を選択します
Postman Send を選択します

Note

Controller responds with a “204 No Content” response and an authentication cookie.
Retail-Development Environment、 Application - trading を開きます Application trading サブフォルダを開き、2) Create Component - main (CAS monitoring) を選択します
Postmanのリクエストエリアにある Body をクリックしてください。PUT リクエストのペイロードを確認してください。 JSONの desiredState, security 配下のプロパティ値は前回のラボでデプロイした Component に関する内容であることが確認できます
Postmaneで Send を選択します

Note

NGINX Controllerは “eventual consistency model” に従います。APIはPostmanのリクエストに “202 Accepted” ステータスコードを返します。 NGINX Controllerは現状動作し、意図した状態であることが確認できます

コンポーネントの変更を確認する

Chromeを開きます。NGINX Controllerに接続しているタブで以下手順に従ってログインします
BookmarkからNGINX Controller UIにアクセスしてください
NGINX Controllerの特権を持たないユーザである Natasha Romanoff でログインしてください

Username	Password
natasha@acmefinancial.net	`Natasha123!@#`

Services メニューを開いてください
Apps を選択します
Trading Application (CAS) appを開きます。Trading Main コンポーネントの**WAF Enablement Status** 、**WAF Monitoring Only Status**が “On” であることを確認できます
Components セクションをクリックしてください

Attribute	Description
Auth Provider Type	Define the authentication provider being used
User Format	Define if the user will login with username@domain (UPN) or domain/user (User Domain)

Field	Value
Name	`controller-3`
Hostname or IP	`10.1.1.10`

Field	Value
Name	`nginxplus-4`
Location	`West Coast Data Center (OTHER_LOCATION)`
Allow insecure server connections to NGINX Controller using TLS	Enable(Check)

Field	Value
Name	`echo`
Display Name	`Echo Environment`

F5 Labs - Index

ようこそ

はじめに

Lab Topology

NGINX Controller Credentials

Module 1 - Enterprise Features

Lab 1 - Active Directory Authentication

Authentication Providersの設定を確認する

Authentication Provider の設定を確認する

追加情報

Lab 2 - NGINX Controller の冗長化

追加するNGINX Controllerのノードを作成する

クラスタにインスタンスを追加するため install command を実行する

View the results

(Optional) Kubernetes Cluster の確認

追加情報

Lab 3 - NGINX Plus の追加

NGINX Plus のインストール

NGINX PlusのインスタンスをNGINX Controllerに追加する

(Optional) NGINX Controllerの管理対象となるNGINX Plusの設定

Module 2 - ADC Application Workflows

Lab 1 - GUIで ADC App の作成

NGINX Controller が持つオブジェクトのコンセプト

Environments

Cert

Gateway

App

Component

Workload Group

Applicationをデプロイする

Environmentを作成する

証明書の追加

Gatewayの作成

Appを作成する

Componentを作成する

Echo Applicationのテスト

Lab 2 - ADC App 作成のプログラマビリティの確認

Trading App の現在の状況を確認

Postmanを利用して Component のデプロイ

Trading App の変更を確認する

Lab 3 - ADC によるより詳細なトラフィック制御機能(Programmability)

App Componentを開く

URI Rewriteを設定する

Request Header 変更機能を設定する

追加情報

Lab 4 - TCP Load Balancing / Routing

App Componentを開く

TCP Component を作成する

TCP Componentをテストします

追加情報

Lab 5 - 待ち受ける特定のアドレスを定義する

Gatewayの待ち受けるIPアドレスを定義する

Gatewayを作成する

Component を作成する

Listen IP Component をテストする

Lab 6 - Security トラフィックジェネレータ を実行する

Analytics に利用する WAF Traffic Generation の実行

Module 3 - Analytics

Lab 1 - NetOps/Admin向けAnalytics

Dashboard概要

Instance Analytics

Lab 2 - DevOps/Developer向けAnalytics

Dashboard概要

Critical Analytics

Module 4 - Application Security

Lab 1 - Application Security (GUI)

Component の Security を有効にする

Security Analytics を確認する

Security Events を確認する

WAF policy のチューニング

Lab 2 - Application Security (API)

Alter Security Settings in API

Postmanを用いて、Component の Security Settings を更新する

コンポーネントの変更を確認する

おめでとうございます！！ NGINX Controller Lab はこれで完了です。

Lab 6 - Security トラフィックジェネレータを実行する