エージェントコンテナイメージ

Next-Gen WAF エージェント (旧 Signal Sciences エージェント) のコンテナイメージの正式名称は、signalsciences/sigsci-agent です。sigsci-agent コンテナイメージは Docker Hub で入手できます。この画像は signalsciences/sigsci-agent:latest でプルできます (または latest をバージョンタグに置き換えてください)。この画像を修正する必要がある場合、またはローカルでビルドしたい場合は、以下の手順に従ってください。

カスタム sigsci-agent Dockerfile

既存の sigsci-agent コンテナイメージの上に、FROM を使用してビルドできます。ただし、Dockerfile は root ではなく sigsci ユーザーとしてコマンドを実行するように設定されているため、注意が必要です。推奨される Dockerfile を使用する場合、システムの変更を行った後、root ユーザーに変更し、その後 sigsci ユーザーに戻す必要がある場合があります。

例：追加パッケージのインストール

# Start from the official sigsci-agent container
FROM signalsciences/sigsci-agent:latest

# Change to root to install a package, using `sl` as an example
USER root
RUN apk --no-cache add sl

# Change back to the sigsci user at the end for runtime
USER sigsci

エージェントの Docker コンテナイメージをビルドする

https://dl.security.fastly.com と https://dl.signalsciences.net の両方で、sigsci-agent ディストリビューション .tar.gz アーカイブで推奨される sigsci-agent Dockerfile をホストしています。アーカイブをダウンロードして解凍し、Docker コンテナイメージをビルドするには、ターミナルアプリケーションで以下のコマンドを実行します。

dl.security.fastly.com
dl.signalsciences.net

$ curl -O https://dl.security.fastly.com/sigsci-agent/sigsci-agent_latest.tar.gz
$ mkdir sigsci-agent && tar zxvf sigsci-agent_latest.tar.gz -C sigsci-agent
$ cd sigsci-agent
$ make docker

IMAGE_NAME (例：make IMAGE_NAME=custom-prefix/sigsci-agent docker) を設定することで、タグにカスタム名を使用できます。

手動でビルドするには、YOUR-TAG と YOUR-VERSION を置き換えて次のコマンドを実行します。

$ docker build . -t your-tag:your-version

Next-Gen WAF エージェントを統合する

Next-Gen WAF エージェントは、各 Pod にサイドカーとしてインストールすることも、特定の要件向けにサービスとしてインストールすることもできます。

Kubernetes に Next-Gen WAF エージェントをインストールするには、sigsci-agent をサイドカー (Kubernetes がネイティブでサポートするマルチコンテナ Pod パターン) として Pod に統合します。これは、sigsci-agent を Kubernetes Pod の追加コンテナとして追加することを意味します。サイドカーとして動作することで、エージェントは個別にスケーリングされるのではなく、Pod 内のアプリケーションやサービスに合わせてスケーリングされます。状況によっては、sigsci-agent コンテナをサービスとしてインストールし、個別にスケーリングするデプロイの方が適している場合もあります。

sigsci-agent コンテナは、インストールタイプや使用するモジュールに応じてさまざまな方法で設定できます。

コンテナフック preStop を使用すると、その Pod のシャットダウンを遅らせ、ドレインタイムアウトを確実に満たすことができます。

preStop:
  exec:
    command:
      - sleep
      - "30"

デフォルトでは、エージェントは予備的な検査のために迅速な起動とパフォーマンス準備を優先します。ただし、ルールや設定データを読み込んだ後にのみトラフィックを検査したい場合、迅速な起動が必ずしも望ましいとは限りません。その場合は、Startup Probe を設定してエージェントの起動を遅延させることを検討してください。

エージェントコンテナイメージを取得および更新する

これらの手順では、latest バージョンのエージェントを imagePullPolicy: Always で参照しており、ローカルにすでにエージェントが存在する場合でも最新のエージェントバージョンを取得します。これは、ドキュメントが古くならないようにし、古い状態のままのエージェントを使い続けることを防ぐためです。

ただし、インストールの一貫性を維持する必要がある場合や、特定バージョンのエージェントを維持する必要がある場合は、この方法が適さない可能性があります。このような場合は、エージェントのバージョンを指定する必要があります。Docker Hub 上のイメージにはバージョンがタグ付けされており、バージョンのリストを確認できます。

latest イメージを使用するか特定のバージョンを使用するかにかかわらず、エージェントを最新の状態に保つために考慮すべき項目がいくつかあります。

`latest` コンテナイメージを使用する

latest イメージを使用することを選択した場合は、エージェントを最新の状態に保つ方法を検討する必要があります。

imagePullPolicy: Always オプションを使用した場合、エージェントは起動時に最新のイメージをプルし、継続的に更新を受け取ります。
あるいは、起動時に常にプルするのではなく、定期的にプルして手動でローカルキャッシュを更新する方法もあります。
```
$ docker pull signalsciences/sigsci-agent:latest
```
次に、latest を imagePullPolicy: Never 設定で使用して、起動時にプルが実行されないようにします (上記のように手動でのみ)。
```
- name: sigsci-agent
    image: signalsciences/sigsci-agent:latest
    imagePullPolicy: Never
    ...
```

バージョン管理されたコンテナイメージを使用する

特定のバージョンのエージェントを使用するには、latest をエージェントのバージョン (ここでは x.xx.x で表される) に置き換えてください。この場合、イメージは更新されるべきではないため、imagePullPolicy: IfNotPresent に変更することもおすすめします。

- name: sigsci-agent
    image: signalsciences/sigsci-agent:x.xx.x
    imagePullPolicy: IfNotPresent
    ...

この方法では、指定したエージェントバージョンがプルされ、ローカルにキャッシュされます。この方法を使用する場合、後でエージェントイメージを更新しやすくするため、Helm などを使ってエージェントイメージをパラメータ化することを推奨します。

コンテナイメージにカスタムタグを使用する

ローカルエージェントイメージにカスタムタグを適用することも可能です。これを行うには、エージェントイメージを (バージョンまたは latest で) プルします。カスタムタグを適用し、そのカスタムタグを設定で使用します。ローカルイメージは手動でのみ更新されるように imagePullPolicy: Never を指定する必要があります。その後、エージェントを最新の状態に保つために、ローカルイメージを定期的に更新する必要があります。

例:

$ docker pull signalsciences/sigsci-agent:latest
$ docker tag signalsciences/sigsci-agent:latest signalsciences/sigsci-agent:testing

次に、このイメージタグを設定で使用します。

- name: sigsci-agent
    image: signalsciences/sigsci-agent:testing
    imagePullPolicy: Never
...

エージェントコンテナを設定する

エージェントの設定は通常、環境変数を通じて行います。ほとんどの設定オプションは環境変数として利用可能です。デフォルトでは、環境変数は次の命名規則に従います。

名前は SIGSCI_ で始まります。
オプション名は大文字で表記します。
ダッシュ (-) はアンダースコア (_) に変更します。

たとえば、max-procs オプションは SIGSCI_MAX_PROCS 環境変数になります。利用可能なオプションの詳細については、エージェント設定ドキュメントを参照してください。

sigsci-agent コンテナには設定が必要ないくつかの必須オプションがあります。

エージェント認証情報 (Agent Access Key と Agent Secret Key)。
一時ファイルを書き込むためのボリューム。

エージェントの認証情報

sigsci-agent の認証情報は、2つの環境変数で設定されます。これらの変数が設定されていない場合、エージェントは起動しません。

SIGSCI_ACCESSKEYID：エージェントアクセスキーは、エージェントが設定されているサイト (ワークスペース) を識別します。
SIGSCI_SECRETACCESSKEY：エージェントシークレットキーはエージェントを認証・認可するための共有秘密鍵です。

これらの値は非常に機密性が高いため、Kubernetes の組み込み secrets 機能を使用することを推奨します。この構成では、エージェントは Deployment 設定内にハードコードされた値を読み取るのではなく、Secrets データから値を取得します。これにより、エージェントの認証情報を1か所で変更するだけで済むため、希望するエージェント認証情報のローテーション管理が容易になります。

secrets 機能を使うには、value オプションではなく valueFrom オプションを使用します。例：

env:
  - name: SIGSCI_ACCESSKEYID
    valueFrom:
      secretKeyRef:
        # Update my-site-name-here to the correct site (workspace) name or similar identifier
        name: sigsci.my-site-name-here
        key: accesskeyid
  - name: SIGSCI_SECRETACCESSKEY
    valueFrom:
      secretKeyRef:
        # Update my-site-name-here to the correct site (workspace) name or similar identifier
        name: sigsci.my-site-name-here
        key: secretaccesskey

secrets 機能は、Kubernetes 内のさまざまなストアにシークレットを保持します。このガイドでは、例として汎用のシークレットストアを使用していますが、同等のストアであればどれでも使用できます。エージェントのシークレットは、以下の例のような YAML を使用して汎用のシークレットストアに追加できます。

apiVersion: v1
kind: Secret
metadata:
  name: sigsci.my-site-name-here
stringData:
  accesskeyid: 12345678-abcd-1234-abcd-1234567890ab
  secretaccesskey: abcdefg_hijklmn_opqrstuvwxy_z0123456789ABCD

これは、次の例のように kubectl を使用して、コマンドラインから作成することもできます。

$ kubectl create secret generic sigsci.my-site-name-here \
  --from-literal=accesskeyid=12345678-abcd-1234-abcd-1234567890ab \
  --from-literal=secretaccesskey=abcdefg_hijklmn_opqrstuvwxy_z0123456789ABCD

Kubernetes の secrets 機能に関する詳細は、Kubernetes のドキュメントを参照してください。

エージェント用の一時ボリューム

セキュリティ強化のため、sigsci-agent コンテナについては、ルートファイルシステムを読み取り専用としてマウントして実行することを推奨します。ただし、エージェントは、RPC 通信用のソケットファイルのような一時ファイルや、位置情報データなどの定期的に更新されるファイルを書き込む必要があります。

読み取り専用のルートファイルシステムでこれを実現するには、書き込み可能なボリュームをマウントする必要があります。この書き込み可能なボリュームは、同じ Pod 内の他のコンテナに RPC ソケットファイルを公開するために共有することもできます。

書き込み可能なボリュームを作成する推奨方法は、組み込みの emptyDir ボリュームタイプを使用することです。これは通常、次の例のように Deployment の volumes セクションで設定します。

volumes:
  - name: sigsci-tmp
    emptyDir: {}

その後、コンテナはこのボリュームを /sigsci/tmp にマウントします。

volumeMounts:
  - name: sigsci-tmp
    mountPath: /sigsci/tmp

公式エージェントコンテナイメージのデフォルト設定では、一時ボリュームが /sigsci/tmp にマウントされます。エージェントコンテナ用にこれを変更する必要がある場合、次のエージェント設定オプションもデフォルトから新しいマウント場所に合わせて変更する必要があります。

rpc-address (デフォルト：/sigsci/tmp/sigsci.sock)
shared-cache-dir (デフォルト：/sigsci/tmp/cache)

Kubernetes インストールの概要

Network services

Security

Compute

Quick start

Building blocks

Integrations

Tutorials

Demos

Use Cases

Code Examples

Starter Kits

エージェントコンテナイメージ

カスタム sigsci-agent Dockerfile

例：追加パッケージのインストール

エージェントの Docker コンテナイメージをビルドする

Next-Gen WAF エージェントを統合する

エージェントコンテナイメージを取得および更新する

`latest` コンテナイメージを使用する

バージョン管理されたコンテナイメージを使用する

コンテナイメージにカスタムタグを使用する

エージェントコンテナを設定する

エージェントの認証情報

エージェント用の一時ボリューム

Network services

Security

Compute

Quick start

Building blocks

Integrations

Tutorials

Demos

Use Cases

Code Examples

Starter Kits

エージェントコンテナイメージ

カスタム sigsci-agent Dockerfile

例：追加パッケージのインストール

エージェントの Docker コンテナイメージをビルドする

Next-Gen WAF エージェントを統合する

エージェントコンテナイメージを取得および更新する

latest コンテナイメージを使用する

バージョン管理されたコンテナイメージを使用する

コンテナイメージにカスタムタグを使用する

エージェントコンテナを設定する

エージェントの認証情報

エージェント用の一時ボリューム

関連コンテンツ

`latest` コンテナイメージを使用する