Box Mount

​

Box Mountの仕組み

• コンテンツはBoxに保持されます。エージェントはローカルパスを対象に操作を実行し、すべての操作はBox APIを介して実行されます。
• ガバナンスはコンテンツに追従します。すべての操作は、Box Mountが認証したIDとして実行されます。そのため、Box Shieldの分類ベースのセキュリティポリシーとともに、そのIDの権限、リテンション、リーガルホールド、情報バリア、監査証跡がエージェントに適用されます。OAuthモードでは、IDはアプリを承認したユーザーです。そのため、ユーザーがアクセスできないコンテンツにエージェントがアクセスすることはできません。JWTモードでは、IDはサービスアカウントです。そのため、そのアカウントのスコープをエージェントが必要とするコンテンツに設定します。
• 同期は双方向で実行されます。エージェントがマウント上で行った変更はBoxにアップロードされ、ユーザーや他のエージェントによる更新はマウントに反映されます。
• 競合は上書きされずに保持されます。ユーザーやエージェントが同じファイルを同時に変更した場合、Box Mountはアップロード時に競合を検出し、両方の結果を新しいBoxバージョンまたは別個の競合コピーとして保持します。そのため、レビュー担当者は変更内容をマージしたり、Boxのバージョン履歴を利用してロールバックしたりできます。

​

Box Mountの実際の動作を確認する

​

始める前に

• Box Mountのバイナリを含む、Box Mountプライベートプレビューへのアクセス権限。アクセス権限をリクエストするには、Box Mountプライベートプレビューの利用申請フォームに必要事項を入力してください。
• 開発者コンソールのBoxアプリ。OAuth 2.0またはJWT認証のいずれかに構成しておきます。
• マウントするBoxフォルダのID。これは、BoxのフォルダURLの末尾の数値です。

​

サポート対象プラットフォーム

​

コマンド

box-mount config
mkdir -p /mnt/box
box-mount mount "/mnt/box" "123456789"
box-mount status

​

資格情報の構成

box-mount config

​

OAuthの手動構成

{
  "client_id":     "YOUR_BOX_CLIENT_ID",
  "client_secret": "YOUR_BOX_CLIENT_SECRET",
  "access_token":  "",
  "refresh_token": "",
  "redirect_uri":  "http://localhost:3000/callback"
}

​

JWTの手動構成

{
  "auth_type": "jwt",
  "jwt_config_path": "/path/to/box-jwt-config.json"
}

​

環境変数の使用

​

開発者トークンの使用

{
  "client_id":     "YOUR_BOX_CLIENT_ID",
  "client_secret": "YOUR_BOX_CLIENT_SECRET",
  "access_token":  "PASTE_DEVELOPER_TOKEN_HERE",
  "refresh_token": ""
}

export BOX_ACCESS_TOKEN="PASTE_DEVELOPER_TOKEN_HERE"
box-mount mount "/local/path" "123456789"

​

トークンのライフサイクル

• アクセストークンは約60分後に期限切れになり、SDKによって自動的に更新されます。
• 更新のたびに更新トークンがローテーションされ、古い更新トークンは即座に無効になります。
• ローテーションされたトークンは~/.box-mount/box-config.jsonに書き戻されます。
• 更新トークンは60日間使用されないと期限切れとなります。box-mount configをもう一度実行すると、OAuthフローが繰り返されます。

• SDKはJWTアサーションに署名し、それを有効期間の短いアクセストークンと交換して、そのトークンを自動的に更新します。トークンはメモリにのみ保持されるため、box-config.jsonには何も書き込まれません。
• JWTの構成JSONと秘密キーが有効であれば、認証にユーザーの操作は必要ありません。

​

資格情報の保護

​

エージェントサンドボックスでの推奨設定

1. 2つのユーザーを作成します。ユーザーAとしてbox-mount configを実行し、~/.box-mount/がユーザーAのホームディレクトリ内に作成されるようにします。まだマウントしないでください。ブートストラップ処理によってツリー構造が生成され、先に共有権限を空のマウントディレクトリに設定する必要があるからです。
2. 資格情報に対するアクセスを、ユーザーAのみが読み取ることができるように制限します。その後、ls -lを使用して所有権を確認します。モード644 (全ユーザーが読み取り可能) は、これらのファイルには適切ではありません。
   chmod 700 ~/.box-mount
   chmod 600 ~/.box-mount/box-config.json
   chmod 600 /path/to/box-jwt-config.json   # JWT mode only
   
3. 共有グループ、setgid、およびデフォルトのPOSIX ACLを使用して、マウントディレクトリのみをユーザーBと共有します。setgidは、グループ所有権を新しいinodeにコピーします。また、デフォルトのACLはグループの書き込みアクセス権限を継承します。この設定を空のディレクトリに適用してから、マウントします。setfaclコマンドはaclパッケージに含まれています。
   sudo mkdir -p /path/to/mount
   sudo groupadd boxmount
   sudo usermod -aG boxmount userA
   sudo usermod -aG boxmount userB
   sudo chown userA:boxmount /path/to/mount
   sudo chmod 2770 /path/to/mount
   sudo setfacl -m g:boxmount:rwx -m d:g:boxmount:rwx /path/to/mount
   box-mount mount "/path/to/mount" "<box-id>"   # as user A
   
   ユーザーBには、ユーザーAのホームディレクトリ、--data-path、およびJWTファイルに対する読み取りアクセス権限を持たせないようにする必要があります。また、ユーザーBはマウントより上位にあるすべてのディレクトリをトラバースできる必要があるため、この例ではマウントをホームディレクトリの外に配置しています。マウントを代わりにユーザーAのホームディレクトリ内に配置しても、ホームディレクトリが750に設定されていると、マウントディレクトリ自体が2770であっても、ユーザーBはブロックされます。
4. ユーザーBとしてエージェントを起動します。エージェントのシェル、systemdユニット、またはコンテナ仕様には、BOX_CLIENT_ID、BOX_CLIENT_SECRET、BOX_ACCESS_TOKEN、BOX_REFRESH_TOKEN、BOX_JWT_CONFIG_PATHをエクスポートしないでください。エクスポートすると、これらの値がプロセス環境から参照可能になります。これらの値は、ユーザーAのデーモンプロセスのみが保持するようにします。
5. JWTモードでは、企業の管理者のキーペアではなく、エージェントが必要とするコンテンツにスコープが設定されたサービスアカウントを使用します。

​

データおよびログの場所

​

既知の制限

​

アトミックセーブの非サポート

​

ワークロードの制限

​

関連ツール