vague memory

うろ覚えを無くしていこうともがき苦しむ人の備忘録

AWS Step Function 組み込み関数でハイフン(ダッシュ)を含む要素を使う

だいぶニッチな要件ですが、公式ドキュメントに記載を見つけられず試行錯誤したのでメモ。

前提

Step Function では、 Amazon States Language でフローを定義します。

パスは $で始まる文字列 となる JsonPath 構文で記述し、ドット表記とブラケット表記が利用できます。
ドキュメント内の例は殆どドット表記で記載されています。

Paths - AWS Step Functions

You can access object fields using only dot (.) and square bracket ([ ]) notation.

json-path/JsonPath: Java JsonPath implementation

JsonPath expressions can use the dot–notation

$.store.book[0].title

or the bracket–notation

$['store']['book'][0]['title']

また、データ処理を行うための組み込み関数がいくつか用意されています。

Intrinsic functions - AWS Step Functions

結論

Parameters では、両表記 "$.detail-type", $['detail-type'] が利用可能です。

Intrinsic functions (組み込み関数) 内でも利用できますが、ハイフンを含む場合は、ブラケット表記 $['detail-type'] のみ利用可能 です。

詳細

例題

AWS の各種 Event に含まれる datail-type を Step Function (StateMachine) で使用します。

"$.detail-type"$['detail-type'] の二通りの記述方式で、単純参照と組み込み関数の利用を試します。
関数は値を利用して新たな文字列を生成する States.Format を利用します。

成功例

input データから値を抽出する簡単な StateMachine で確認します。

{
  "Comment": "hyphen check",
  "StartAt": "Pass: Parameter",
  "States": {
    "Pass: Parameter": {
      "Type": "Pass",
      "Parameters": {
        "detail-type.$": "$.detail-type",
        "[detail-type].$": "$['detail-type']"
      },
      "ResultPath": "$.resultParameter",
      "Next": "Pass: Intrinsic function"
    },
    "Pass: Intrinsic function": {
      "Type": "Pass",
      "Parameters": {
        "detail-type.$": "States.Format('detail-type: {}', $['detail-type'])"
      },
      "ResultPath": "$.resultIntrinsicFunction",
      "End": true
    }
  }
}

失敗例

抜粋です。 States.Format の $['detail-type']$.detail-type になっています。

        "detail-type.$": "States.Format('detail-type: {}', $.detail-type)"

書式エラーとなり、保存できません。

There are Amazon States Language errors in your state machine definition. Fix the errors to continue.

AWS EventBridge API destinations で Typetalk へ投稿する

API destinations とは、EventBridge から直接 HTTP エンドポイント へ送信できる機能です。

Typetalk とは、Nulab 提供のチャットサービスです。

AWSで発生したイベントを Typetalk に流します。



Typetalk

Nulab製品同士であればシームレスに連携できますが、他サービスの場合はボット機能で連携させます。

ボットの作成

"トピックメニュー" -> "トピック設定" -> "ボット" -> "新規追加" から作成します。

ボットに発言させるので、 topic.post を有効にします。 デフォルト有効です。

トークンの取得

ボットを作成すると、 "Typetalk Token" と "メッセージの取得と投稿の URL" が払い出され、これらを使用してアクセスすることになります。

記述方式として2パターン使えます。

  • 認証と認可 | Typetalk Developer API | Nulab
    • ヘッダ X-Typetalk-Token: YOUR_TYPETALK_TOKEN
      • "メッセージの投稿コマンドサンプル" はこちらの形式になっています。
    • パラメータ typetalkToken=YOUR_TYPETALK_TOKEN
      • 例: https://typetalk.com/api/v1/topics/xxxxx?typetalkToken=YOUR_TYPETALK_TOKEN

Amazon EventBridge

AWSマネジメントコンソールから作成する場合、作成ウィザードが統合されており、 rule の作成から併せて作成することもできます。

個別に作成する場合は、 Connection、API destination、Rule の順で作成していきます。

Connection 作成

Amazon EventBridge -> API destinations -> Connections から作成します。

  • Destination type: Other
    • サポートされているパートナーであれば Partners から選択し、必要パラメータが埋まった状態になりますが、Otherでは全て自前で設定してく形となります。
  • Authorization type: API Key
    • Typetalkで作成したトークンとヘッダを指定します。
      • API key name: X-Typetalk-Token
      • Value: YOUR_TYPETALK_TOKEN

API key は Secrets Manager に設定されます。

# Secret name: `events!connection/{API destination name}/xxxxx`

{"api_key_name":"X-Typetalk-Token","api_key_value":"YOUR_TYPETALK_TOKEN"}

API destination 作成

Amazon EventBridge -> API destinations から作成します。

  • API destination endpoint: https://typetalk.com/api/v1/topics/xxxxx
    • Typetalkで作成した "メッセージの取得と投稿の URL" を指定します。
  • HTTP method: POST
  • Use an existing connection:
    • 作成済みの Connection を指定します。

Rule 作成

Amazon EventBridge -> Rules から作成します。

  • Target types: EventBridge API destination
  • API destination:
  • Execution role:
    • IAM Role が自動生成されます。事前に作成しておき選択することもできます。

Additional settings を開き、追加設定を行います。

  • Configure target input: Input transformer
    • "Configure input transformer" を押下し、変換設定を行います。(後述)
  • Dead-letter queue:

Execution role について

自動生成される IAM Role のポリシーは以下の通りです。

Trust relationship
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "events.amazonaws.com"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}
Permission
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "events:InvokeApiDestination"
            ],
            "Resource": [
                "arn:aws:events:ap-northeast-1:123456789012:api-destination/{API Destination Name}/*"
            ]
        }
    ]
}

Configure input transformer 設定

Amazon EventBridge input transformation - Amazon EventBridge

EventBridge で受信した Event を Typetalk へ送信するための形式に変換します。

Event により大きく変わるため、細かな部分を省きますが今回の設定例は以下の通りです。

input path

"Security Hub Findings - Imported" Event を題材にします。

{
  "Account": "$.account",
  "Description": "$.detail.findings[0].Description",
  "DetailType": "$.detail-type",
  "FirstSeen": "$.detail.findings[0].FirstObservedAt",
  "LastSeen": "$.detail.findings[0].LastObservedAt",
  "Recommendation": "$.detail.findings[0].ProductFields.RecommendationUrl",
  "Region": "$.region",
  "Resource": "$.detail.findings[0].Resources[0].Id",
  "Severity": "$.detail.findings[0].Severity.Label",
  "Summary": "$.detail.findings[0].Title"
}
Input template

メッセージを投稿する | Typetalk Developer API | Nulab

Typetalk に投稿するため、 { "message": "" } の形式にします。

{
    "message": ":warning: [<Severity>] <DetailType> | <Region> | Account: <Account>\n\n<Summary>\n> <Description>\n```\nFirst Seen: <FirstSeen>\nLast Seen: <LastSeen>\nAffected Resource: <Resource>\nSeverity: <Severity>\nRecommendation: <Recommendation>\n```"
}

通知確認

正しく設定が行われていれば、AWS上での Event 発生時に Typetalk へ投稿されます。

AWS Chatbot での Slack 通知に似せ、且つ、使える書式を全て使ってみました。

Typetalk

Slack (Chatbot)

まとめ

Terraform 化した物を以下に置いてます。

Typetalk ではトピック毎にボットを設定し、ボット毎にAPI Keyが払い出される仕様であるため、 複数トピックを運用したい場合は一連のリソースをそれぞれ作成する必要があります。

API destination の Endpoint にパラメータ形式で API Key を直接埋め込む事も可能ですが、Secrets Manager 統合が成されているのでヘッダ形式での設定がお薦めです。

余談

普段は Slack + Chatbot を利用しており、API destination を使う機会が無かったのですが、 これまで EventBridge -> SNS Topic -> Lambda Function などで処理していた部分を EventBridge(API destination + Input transformer) 単体で管理できるのは良いと思いました。

受信したイベントそれぞれに対応して Input transformer で変換を掛けていかないとならないのが難点です。

Chatbot で大部分のイベントをサポートしているので、その整形部分を利用できるようになるとまた変わってくるかもしれません。 現状、正常の場合はログにもイベントは残らないようなので期待薄でしょうかね。

AWSume で SSO profile を使用する

AWSのSwitchRole運用に役立つ便利ツール AWSume ですが、AWS SSO (AWS IAM Identity Center (successor to AWS Single Sign-On)) での利用は今の所ネイティブサポートされていません。

発生するエラー

Awsume error: Invalid profile [xxxxx] Missing keys aws_access_key_id, aws_secret_access_key, or credential_source, or credential_process

回避策

Issue に記載がありますが、AWS_CONFIG_FILE に credential_process を設定することで利用可能になります。

Issue 内のリンクは benkehoe/aws-sso-credential-process を指していますが、 後継として benkehoe/aws-sso-util が公開されているのでこちらを利用します。

Install

pipx install aws-sso-util 

AWS_CONFIG_FILE

SSOのプロファイル設定に credential_process を追加します。

AWS IAM Identity Center (successor to AWS Single Sign-On) を使用するための AWS CLI の設定 を例に取ると以下のようになります。

[profile my-dev-profile]
sso_start_url = https://my-sso-portal.awsapps.com/start
sso_region = us-east-1
sso_account_id = 123456789011
sso_role_name = readOnly
region = us-west-2
output = json
# ※ 追加
credential_process = aws-sso-util credential-process --profile my-dev-profile

AWS 多段スイッチロール(ロールの連鎖) でマネジメントコンソールへログイン

年の瀬の awsume-console-plugin との出会いです。



馴れ初め

  • 🤷:多段スイッチロールだとマネジメントコンソール使えなくなりますね
  • 👼:awsume でできるんじゃない
  • 🤷:マネジメントコンソールの仕様上できないっぽいですけど
  • ...
  • 🤷:できた

結論

AWSumeプラグイン awsume-console-plugin を利用する多段スイッチロールでもマネジメントコンソールへの Sign-in が行えます。

神と紹介されていますが、正にでした。


検証

スイッチロール

マネジメントコンソールと AWC CLI (など) で仕様が異なります。

AWS Management Consoleでロールを切り替えると、コンソールは常に元の認証情報を使用して切り替えを認証します。
これは、IAM ユーザー、SAML フェデレーションロール、またはウェブ ID フェデレーションロールとしてサインインする際に適用されます。
たとえば、RoleA に切り替える場合は、IAM は元のユーザーまたはフェデレーションロールの認証情報を使用して、RoleA の引き受けが許可されているかどうかを判断します。
その後、RoleA を使用中に RoleB への切り替えを試みると、AWS は引き続き RoleA の認証情報ではなく元のユーザーまたはフェデレーティッドロールの認証情報を使用して切り替えを承認します。

ロールの連鎖 — ロールの連鎖を使用することもできます。この連鎖は、ロールのアクセス許可を使用して 2 つ目のロールにアクセス許可を使用します。 コンソールでロールを切り替えるときは、ロールチェーンを使用していません。元のユーザーの権限を使用しています。

ロールの連鎖についての説明は以下になります。

ロールの連鎖

ロールの連鎖は、AWS CLI または API を使用して 2 つ目のロールを引き受けるロールを使用する場合に発生します。
たとえば、RoleA には RoleB を引き受けるアクセス権があります。
User1 は AssumeRole API オペレーションの長期的なユーザー認証情報を使用して RoleA を引き受けることができます。
このオペレーションを用いて RoleA の短期的な認証情報を返します。
ロールが連鎖していれば、User1 によって RoleB が引き受けられるよう RoleA の短期的な認証情報を使用できます。

マルチアカウントでの認証

基本的な考え方は公式の図を拝借します。

最近は Idp でのフェデレーションや、AWS Organization で IAM Identity Center (旧AWS SSO) の利用が主流となっていますが、 "IAMユーザー" が "IAMロール" に置き換わるだけで基本的な考え方は同じだと思います。

パターン1: Sign-in ユーザにスイッチ許可

  • "IAM User" に各AWSアカウントの IAM Role へのSwitchを許可

基本構成です。
"IAM User" で Sign-in 後に "Switch role" で、各AWSアカウントのRoleへSwitchします。 "Switch back" で元のAWSアカウントの "IAM User" に戻ります。

以下は AWS_CONFIG_FILE (~/.aws/config) の最低限の記載例です。

# AWS_CONFIG_FILE 例
[profile assume-a]
source_profile = default
role_arn = arn:aws:iam::XXXXXXXXXXXa:role/example-switch-role-assume-a

[profile assume-b]
source_profile = default
role_arn = arn:aws:iam::XXXXXXXXXXXb:role/example-switch-role-assume-b

[profile assume-c]
source_profile = default
role_arn = arn:aws:iam::XXXXXXXXXXXc:role/example-switch-role-assume-c

[profile assume-d]
source_profile = default
role_arn = arn:aws:iam::XXXXXXXXXXXd:role/example-switch-role-assume-d

マネジメントコンソール上での Switch role 後の Switch role

前述の仕様により、マネジメントコンソールでは不可です。(図内黄色矢印)

例として "b" に Switch role 後に "c" に Switch role という操作を行った場合、 "b" から "c" でなく、 "A" の IAM User から "c" への Switch となります。 つまり、Switch back 後に再度 Switch role した事と同じ動きになります。(図内赤色矢印)

パターン2: Roleにスイッチ許可

  • "IAM User" に IAM Role へのSwitchを許可し、その Role に各AWSアカウントの IAM Role へのSwitchを許可

図内黄色矢印の Switch はマネジメントコンソールでは不可です。

# AWS_CONFIG_FILE 例
[profile assume-a]
source_profile = default
role_arn = arn:aws:iam::XXXXXXXXXXXa:role/example-switch-role-assume-a

[profile assume-b]
source_profile = assume-a
role_arn = arn:aws:iam::XXXXXXXXXXXb:role/example-switch-role-assume-b

[profile assume-c]
source_profile = assume-a
role_arn = arn:aws:iam::XXXXXXXXXXXc:role/example-switch-role-assume-c

[profile assume-d]
source_profile = assume-a
role_arn = arn:aws:iam::XXXXXXXXXXXd:role/example-switch-role-assume-d

パターン3: ロールの連鎖

  • "IAM User" に IAM Role へのSwitchを許可し、Switch 後の Role へも個別にAWSアカウントの IAM Role へのSwitchを許可

この構成は殆ど目にすることは無いと思いますが、一応できるという事で多段スイッチロールを重ねてみます。 同様に、図内黄色矢印の Switch はマネジメントコンソールでは不可です。

# AWS_CONFIG_FILE 例
[profile chain-a]
source_profile = default
role_arn = arn:aws:iam::XXXXXXXXXXXa:role/example-switch-role-chain-a

[profile chain-b]
source_profile = chain-a
role_arn = arn:aws:iam::XXXXXXXXXXXb:role/example-switch-role-chain-b

[profile chain-c]
source_profile = chain-b
role_arn = arn:aws:iam::XXXXXXXXXXXc:role/example-switch-role-chain-c

[profile chain-d]
source_profile = chain-c
role_arn = arn:aws:iam::XXXXXXXXXXXd:role/example-switch-role-chain-d

ちなみにアンチパターンでしかないと思いますが、循環(更に d から b へ Switch など)もやろうと思えばできます。

Awsume Console Plugin

本題です。

AWSumeプラグイン awsume-console-plugin を利用すると各パターンの任意の AWSアカウント、ロールでマネジメントコンソールへの Sign-in が行えます。

インストール

pipx install awsume 
pipx inject awsume awsume-console-plugin 

Sign-in URLの発行

-c でデフォルトブラウザで開く、 -cl で URL 出力です。

Sign-in 後の Switch role も可能です。(図内紫色矢印)

例:パターン2 の Role(a)

$ awsume assume-a -cl
[assume-a] Role credentials will expire YYYY-MM-DD hh:mm:ss
https://signin.aws.amazon.com/federation?Action=login&Issuer=&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2Fconsole%2Fhome%3Fregion%3Dus-east-1&SigninToken=...

例:パターン3 の Role(a)

% awsume chain-b -cl
[chain-a] Role credentials will expire YYYY-MM-DD hh:mm:ss
[chain-b] Role credentials will expire YYYY-MM-DD hh:mm:ss
https://signin.aws.amazon.com/federation?Action=login&Issuer=&Destination=https%3A%2F%2Fconsole.aws.amazon.com%2Fconsole%2Fhome%3Fregion%3Dus-east-1&SigninToken=...

Sign-in 前には Sign out が必要

発行されたURLで Sing-in を行う際に既にAWSマネジメントコンソールへログインしている場合は、一度 Sign out が必要です。

New Relic infrastructure agent の guided install には User key も必要

New Relicinfrastructure agent をインストールする際に license key 無効で失敗したのでメモ。

FATAL could not fetch license key for account 9999999: 401 response returned: Invalid credentials provided. Missing API key or an invalid API key was provided.


結論

記載の手順に沿って実施すれば発生しません。

ガイドを勧めていくと表示されるコマンドを実行する際に既存の API key を利用してインストールしようとした所発生しました。 原因は User key ではなく License key を使っていたからです。

コマンド一撃でインストールできる親切設計ですが、エラーメッセージは若干不親切だと思いました。

以上

guided install について

最初に表示されるのは License key です。

次にインストールコマンドが案内され、こちらを監視対象ホストで実行すると infrastructure agent がインストールされます。 ここで変数 NEW_RELIC_API_KEY が入っていますが、これは User key です。

User Key を作成していない状態で上記の画面まで進めると、自動的に User key が生成されます。手動で User Key を生成する必要がありません。 Installer API Key という名称で User key が作成されていました。

"Customize your installation" の部分で proxy URL の指定を追加できます。

監視対象ホストでコマンドを実行すると、経過状況が出力され、

インストールが完了します。

guided install で設定される License key

インストールが完了すると各設定ファイル群が作成されています。License key は newrelic-infra.yml に設定されます。

$ cat /etc/newrelic-infra.yml
enable_process_metrics: true
status_server_enabled: true
status_server_port: 18003
license_key: *****

ガイドの手順を実行する際に既に複数の License key を持っている場合、 必ずしもガイドの最初に表示されていた License key が設定されるわけではないようです。

明示的に特定の License key にしたい場合は、インストール後に newrelic-infra.yml の書き換えが必要になります。 または、インストールコマンドに環境変数 NRIA_LICENSE_KEY を付与することで指定できるようです。

API Key の種類について

License key

ライセンスキーは、ほぼすべてのデータの報告に使用されます

Browser key

ブラウザキーは、 ブラウザモニタリング データを報告するために使用されます。

Mobile app token

モバイルアプリトークンは、 モバイルモニタリング のデータを報告するために使用されます。

User key

NerdGraph 、データの問い合わせや機能の設定に使用するGraphQL APIを使用する際に、ユーザーキーが必要となります。

上の3つは ingest type (データを New Relic に取り込むためのもの)で、 User key だけ API 利用のためのキーとなっています。

User key が必要な理由

よくよく見ると、インストールコマンドで指定している Key の書式が License key (小文字) ではなく User key (大文字ハイフン有り) です。

また、ガイドの Customize の説明部分に infrastructure agent に加え、CLI もインストールするとの記載があります。 インストールコマンドの URL も newrelic-cli/script.sh となっています。

guided install は New Relic CLI を使用している

New Relic command line interface (CLI) の使用には User key が必要です。

For this guide you just need:

Your New Relic user key. An instrumented application in your New Relic account.

guided install は New Relic CLI で行われるため User key の指定が必要ということになります。

Twingate Headless Client

前回 に続き Twingate ネタです。

Twingate では CI/CD 向けの Headless Client が利用できます。

Linux Headless Mode | Docs | Twingate

CUI で使えるということで試してみます。
GUI同様特に詰まらず、簡単に導入できました。



事前準備

Headless mode requires a Service Key

まず、Service Key が必要になります。 払い出しの方法は公式ドキュメントに記載があります。

Web UI での操作は上記ドキュメント参照です。

今回は API を利用して作成します。 API実行には tg-cli (v0.0.53) を使用しました。
尚、Terraform の Twingate Provider は、現時点で service 関連はサポートしていないようです。

サービスの作成

例として、"test" サービスに2つのリソースを付与して作成します。

#   Usage:   tg service create <name> [resourceNamesOrIds...]

$ tg service create "test" '1.example.com' '2.example.com'

[SUCCESS] New service named 'test' created with id '***' with added resources '1.example.com: *****==' '2.example.com: *****=='

作成したサービスの確認

$ tg service list

┌──────────────────────────────────────────────────────────────────────┬────────────┬───────────┬───────────┬───────────────────────────────────────────────────────┬────────────────┐
│ id                                                                   │ name       │ createdAt │ updatedAt │ resources                                             │ keysTotalCount │
├──────────────────────────────────────────────────────────────────────┼────────────┼───────────┼───────────┼───────────────────────────────────────────────────────┼────────────────┤
│ xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx │ test       │ 10/15/22  │ 10/15/22  │ 1.example.com, 2.example.co....                       │ 0              │
└──────────────────────────────────────────────────────────────────────┴────────────┴───────────┴───────────┴───────────────────────────────────────────────────────┴────────────────┘

list コマンドで取得できる id をキーの作成時に使用します。

WebUI 上でもTeam 配下に "test" Service が作成された事を確認できます。

URL に id が入っています。

キーの作成

"test" サービスにキーを追加します。

#   Usage:   tg service key_create <serviceAccountId> <keyName> <expirationTimeInDays>

$ tg service key_create "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" "tmp_key" "1"

[SUCCESS] Created key 'tmp_key: XXXXX==' at service 'test: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' with token object:
{"version": "1", "network": "subdomain.twingate.com", "service_account_id": "XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX", "private_key": "-----BEGIN PRIVATE KEY-----\n...\n-----END PRIVATE KEY-----", "key_id": "XXXXX", "expires_at": "YYYY-MM-DDTHH:MM:SS+00:00", "login_path": "/api/v2/headless_node/login"}

出力される JSON 文字列が Headless Client で使用する Service Key になります。 後から確認はできないので忘れずに保存しておきます。

WebUI 上でも Service Key が作成された事を確認できます。

Headless Client インストール

試した環境は Ubuntu 20.04.5 LTS (Focal Fossa) です。

$ curl https://binaries.twingate.com/client/linux/install.sh | sudo bash

作成した Service Key を /etc/twingate/ 配下に置き、 setup を実行します。

$ ls /etc/twingate/service_key.json

/etc/twingate/service_key.json

$ sudo twingate setup --headless /etc/twingate/service_key.json

Twingate Setup 1.0.68.54158 | 0.136.0
Setup is complete.

正常にインストールできており、 Service Key が正しければ online になります。

$ sudo twingate start

Starting Twingate service in headless mode
Twingate has been started
Waiting for status...
online

Service Key の内容が正しくない場合などは起動に失敗します。

$ sudo twingate start

Starting Twingate service in headless mode
Twingate has been started
Waiting for status...
not-running

動作確認

IPアドレス制限があり通常は 403 を返却する URL に対しアクセスしてみると、Headless Client が起動している際は拒否されず正常に接続できることが確認できました。

  • offline の状態
$ sudo twingate status

not-running

$ curl -Ls -o /dev/null  https://1.example.com -w '%{http_code}\n'

403
  • online の状態
$ sudo twingate status

online

$ curl -Ls -o /dev/null  https://1.example.com -w '%{http_code}\n'

200

Service Key を Revoke・Delete した場合、 Headless Client の起動が行えなくなります。
Headless Client が online の状態で、Revoke・Delete した場合、 Headless Client が終了するまでは接続可能でした。(どこかのタイミングで不可になるかもしれませんが、試した範囲では可能でした。)

ログ

  • For live review of logs, the Linux Client runs as a systemd service with logs retrievable via journalctl. Below is an example command:
    • sudo journalctl -u twingate --since "1 hour ago"
  • If journalctl is not installed, the logs will be stored under /var/log/twingated.log. This occasionally is seen when running the Linux Client on a container in headless mode.

上記記事の通りですが、試した環境では syslog に吐かれていました。 プロセスとしては twingated, twingate-cli があるようです。


2022/11/11 追記

Service Key は請求対象です。
アクティブユーザと同じ扱いになり、 Service Key を利用してリソース接続を行うと課金対象になります。
プランによっては 1ユーザで複数デバイス利用できますが、 Headless Client はデバイスとしての利用にはならず、別のユーザとしてカウントされます。 (ドキュメント上で記載が見つけられなかったのでサポートに確認しました。)

Twingate Admin API

TwingateAPI を調べる機会があったのでメモ。



概要

GraphQLベースの Admin API が公開されています。 Web UI 上の操作は一通り行えるようです。

GitHub上で PythonJavascript 製の CLI も公開されています。 若干サポートしている機能の違いが有りました。

Getting Started with the API | Docs | Twingate

どのような情報が取得できるかの例は PostMan Collection が公開されているので、 Postman へ import することで簡単に確認できます。

導入と実行例

各ツールでオプション名が違い若干混乱しますが、基本的には network 名 (URL の https://xxx.twingate.com/ 部分) と API Key を指定することで利用できます。

直接実行(curl)

curl で Connector の Status を取得したいとなったら以下の様な感じで取得できます。

$ NETWORK=""
$ URL="https://${NETWORK}.twingate.com/api/graphql/"
$ API_KEY =""

$ curl -L -X POST "${URL}" \
-H "X-API-KEY: ${API_KEY}" \
-H "Content-Type: application/json" \
--data-raw '{"query":"{\n  connectors(after: null, first:10) {\n    edges {\n      node {\n        id\n        name\n        state\n        lastHeartbeatAt\n\n      }\n    }\n    pageInfo {\n      startCursor\n      hasNextPage\n    }\n  }\n}","variables":{}}'
{
  "data": {
    "connectors": {
      "edges": [
        {
          "node": {
            "id": "IDx8US0zIx7nt3uEibDip",
            "name": "example-connector-01",
            "state": "ALIVE",
            "lastHeartbeatAt": "2022-10-09T21:47:18.762481+00:00"
          }
        },
        {
          "node": {
            "id": "IDxpTR7cwIkECA5l9Q9G",
            "name": "example-connector-02",
            "state": "ALIVE",
            "lastHeartbeatAt": "2022-10-09T21:46:57.830308+00:00"
          }
        }
      ],
      "pageInfo": {
        "startCursor": "CURxv85etCrXeEyOShWN6oXm=",
        "hasNextPage": false
      }
    }
  }
}

Twingate-Labs/Twingate-CLI

A Python based Command Line Interface (CLI)

Usage

requests,pandas を使用しているため事前にインストールが必要です。

# 依存パッケージのインストール
$ pip install -U requests pandas

# Usage
$ python tgcli.py -h
usage: tgcli.py [-h] [-v] [-l DEBUGLEVEL] [-s SESSIONNAME]
                [-f OUTPUTFORMAT]
                {auth,device,connector,user,group,resource,network,account,key,policy}
                ...

positional arguments:
  {auth,device,connector,user,group,resource,network,account,key,policy}

optional arguments:
  -h, --help            show this help message and exit
  -v, --version         show program's version number and exit
  -l DEBUGLEVEL, --log DEBUGLEVEL
                        DEBUG,INFO,WARNING,ERROR
  -s SESSIONNAME, --session SESSIONNAME
                        Session Name
  -f OUTPUTFORMAT, --format OUTPUTFORMAT
                        Output Format <JSON,CSV,DF>

Example

SESSIONNAME オプション未指定の場合、自動生成されます。

$ NETWORK=""
$ API_KEY=""

# Get session name
$ python tgcli.py auth login --tenant ${NETWORK} --apikey ${API_KEY}

#Session Created: OrangeEel

作成した SESSIONNAME を使用して実行します。

$ SESSION=OrangeEel
$ python tgcli.py -s ${SESSION} connector list
[
  [
    {
      "node": {
        "id": "IDx8US0zIx7nt3uEibDi",
        "name": "example-connector-01",
        "state": "ALIVE",
        "lastHeartbeatAt": "2022-10-10T22:49:59.988005+00:00",
        "createdAt": "2022-09-25T03:49:01.543217+00:00",
        "updatedAt": "2022-10-03T07:51:03.236550+00:00",
        "hasStatusNotificationsEnabled": false
      }
    },
    {
      "node": {
        "id": "IDxpTR7cwIkECA5l9Q9G",
        "name": "example-connector-02",
        "state": "ALIVE",
        "lastHeartbeatAt": "2022-10-10T22:50:20.686008+00:00",
        "createdAt": "2022-09-25T04:12:10.726199+00:00",
        "updatedAt": "2022-10-03T07:51:47.279982+00:00",
        "hasStatusNotificationsEnabled": false
      }
    }
  ]
]

Twingate-Labs/tg-cli

A javascript based Command Line Interface (CLI)

Usage

バイナリが公開されています。

# ダウンロードとインストール
$ curl -L 'https://github.com/Twingate-Labs/tg-cli/releases/latest/download/cli_linux_x86_64.zip' -o /usr/local/src/tg-cli.zip
$ unzip /usr/local/src/tg-cli.zip -d /usr/local/bin/
$ chmod +x /usr/local/bin/tg

# Usage
$ tg --help

  Usage:   tg
  Version: CLI Version: 0.0.53 | TwingateApiClient Version: 0.1.0

  Description:

    CLI for Twingate

  Options:

    -h, --help                      - Show this help.
    -V, --version                   - Show the version number for this program.
    -a, --account-name  <string>    - Twingate account name
    -l, --log-level     [logLevel]  - Log level                                  (Default: "INFO", Values: "TRACE", "DEBUG", "INFO", "WARN",
                                                                                 "ERROR", "SEVERE", "FATAL", "QUIET", "SILENT")

  Commands:

    export     - Export from account to various formats
    import     - Import from excel file to a Twingate account
    deploy     - Automatically deploy Twingate Connectors to various clouds and platforms
    resource   - Twingate resources
    group      - Twingate groups
    user       - Twingate users
    network    - Twingate networks
    connector  - Twingate connectors
    device     - Twingate devices
    service    - Twingate services
    policy     - Twingate policies

Example

API Key を都度入力する形です。ファイルに保存して使い回すことができます。

$ NETWORK=""

# 初回実行時に API Key を入力
$ tg --account-name ${NETWORK} connector list
 ? Enter Twingate account: (xxxxx) › xxxxx
 ? Enter API key: › **************************************************************************************************************************************

# API Key を `~.tgkeys` に保存するか否か
 ? Save account and API key to file? › Yes
[INFO]    Configuration file saved.
┌──────────────────────┬───────────────────────┬───────────┬───────────┬─────────────────┬────────┬──────────────────────┐
│ id                   │ name                  │ createdAt │ updatedAt │ lastHeartbeatAt │ state  │ remoteNetworkLabel   │
├──────────────────────┼───────────────────────┼───────────┼───────────┼─────────────────┼────────┼──────────────────────┤
│ IDx8US0zIx7nt3uEibDip │ example-connector-01 │ 9/25/22   │ 10/3/22   │ 10/10/22        │ Online │ example-remote-network │
├──────────────────────┼───────────────────────┼───────────┼───────────┼─────────────────┼────────┼──────────────────────┤
│ IDxpTR7cwIkECA5l9Q9G │ example-connector-02 │ 9/25/22   │ 10/3/22   │ 10/10/22        │ Online │ example-remote-network │
└──────────────────────┴───────────────────────┴───────────┴───────────┴─────────────────┴────────┴──────────────────────┘

API Key の保存を行うと、次回以降は Key の入力を省略できます。

$ file .tgkeys
.tgkeys: data
$ tg --account-name ${NETWORK} connector list --output-format json
[INFO]    Using Twingate account: 'xxxxx'
[{"id":"IDx8US0zIx7nt3uEibDip","name":"example-connector-01","createdAt":"2022-09-25T03:49:01.543Z","updatedAt":"2022-10-03T07:51:03.236Z","lastHeartbeatAt":"2022-10-10T23:09:00.021Z","state":"Online","remoteNetworkLabel":"example-remote-network"},{"id":"IDxpTR7cwIkECA5l9Q9G","name":"example-connector-02","createdAt":"2022-09-25T04:12:10.726Z","updatedAt":"2022-10-03T07:51:47.279Z","lastHeartbeatAt":"2022-10-10T23:09:20.694Z","state":"Online","remoteNetworkLabel":"example-remote-network"}]

export

サブコマンドとして export が用意されており、全情報を JSONExcel 形式で出力できます。

$ tg export --help

  Usage:   tg export
  Version: CLI Version: 0.0.53 | TwingateApiClient Version: 0.1.0

  Description:

    Export from account to various formats

  Options:

    -h, --help                         - Show this help.
    -a, --account-name     <string>    - Twingate account name
    -l, --log-level        [logLevel]  - Log level                (Default: "INFO")
    -f, --format           [value]     - Export format            (Default: "xlsx", Values: "xlsx", "json", "dot", "png",
                                                                  "svg")
    -o, --output-file      [value]     - Output filename
    -n, --remote-networks  [boolean]   - Include Remote Networks
    -r, --resources        [boolean]   - Include Resources
    -g, --groups           [boolean]   - Include Groups
    -u, --users            [boolean]   - Include Users
    -d, --devices          [boolean]   - Include Devices (trust)

Twingate/twingate | Terraform Registry

番外編 Terraform の provider です。 現時点ではいくつか対応していない機能があります。

  • Remote Network の "Location" 設定
  • User の Group 割当
  • Connector の "Status emails" 設定

まとめ

使い込んではいませんので所感です。

export/import があり導入も手軽なので、 tg-cli (JavaScript版) の使い勝手が良さそうです。

Twingate-CLI (Python版) の固有機能として DataFrame での出力ができる点がありますが、今の所利用シーンが思い浮かびません。