継続は力なり

タイトル通り定期的な更新を心掛けるブログです。

Bytebase でカスタムロールを作り,専用の承認プロセスを作る

タダです.

Bytebase のデータベース変更の承認を行う際に,デフォルトで用意されているロール以外に承認権を与えたい場合があり,カスタムロールの作成と承認プロセスを設定したので備忘録として記事に書きます.

Bytebase におけるカスタムロール

Bytebase には初期状態で次のロールが用意されています.これらのロール以外にロールを追加したい場合にカスタムロールを作る必要があります.なお,カスタムロールは Enterprise プランでしか使えません.

ロール名 役割の概要
Workspace Admin ワークスペース内のすべての権限を持つ
Workspace DBA ワークスペースメンバの管理を除く,ワークスペース内のすべての権限を持つ
Workspace Member ワークスペース内で最も基本的な役割
Project Owner プロジェクト内のすべての権限を持つ
Project Developer すべての閲覧権限,データベースの変更を要求する権限。
Project Releaser すべての閲覧権限,リリース目的のデータベース変更要求のレビュー権限
Project Querier データベースのデータを照会するための権限
Project Exporter データベースデータをエクスポートするための権限
Project Viewer 基本的なプロジェクト情報の閲覧,データベースへのアクセス等読み取り専用権限

www.bytebase.com

カスタムロールの作成

Settings > Custom Roles のページに遷移します.ロール名,ロールの説明,付与する権限をチェックボックスに入れて有効化します.権限については + Import from role から初期状態で設定されているロールに付与されている権限を取り込むこともできます.

カスタム承認フローの作成

作成したカスタムロールを承認フローに追加してみます.Security & Policy > Custom Approval > Approval Flows にカスタムロールを追加できます. Approval nodes に追加したカスタムロールをプルダウンから選択すれば,追加できます.追加したカスタム承認フローを適用を行う場合は, Security & Policy > Custom Approval > Rules にオペレーションごとの承認を必要とする箇所(例えば,DDL の Default に設定する等)に指定ができます.

まとめ

Bytebase のカスタムロールの追加とカスタムロールを承認フローを

関連記事

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

sadayoshi-tada.hatenablog.com

Amazon Workspace を Microsoft EntraID の SAML 認証を行う~設定編~

タダです.

Amazon Workspaces(以下,Workspaces)のログインを Microsoft EntraID の SAML 認証で設定する事があったので今回は SAML 認証設定編です.なお,前回記事は以下になります.

sadayoshi-tada.hatenablog.com

Workspaces のログインを SAML 認証設定でやること

以下のドキュメントにステップが書かれているため,この記事でも沿って書いていきます.

docs.aws.amazon.com

設定工程

事前準備

事前準備として Microsoft EntraID のエンタープライズアプリケーションから SAMLメタデータを取ってくる必要があるので,その設定をまず行います.エンタープライズアプリケーションの SAML 設定でこちらの URL からダウンロードした saml-metadata.xml をアップロードします.アップロードして保存後にフェデレーションメタデータXML ファイルをダウンロードしておきます.

AWS IAM で SAML ID プロバイダーを作成する

IAM で SAML ID プロパイダーを追加します.事前準備でダウンロードしたフェデレーションメタデータ XML ファイルをアップロードして保存します.

SAML 2.0 フェデレーション IAM ロールを作成する & SAML 2.0 ID プロバイダーを設定する

追加した SAML ID プロバイダーを信頼関係に指定した IAM ロールを作ります.ドキュメントの手順に沿って最終的に以下のポリシーを作成できていれば OK です.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::[AWS アカウント番号]:saml-provider/[追加した SAML ID プロバイダー名]"
      },
      "Action": [
        "sts:AssumeRoleWithSAML",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "SAML:sub_type": "persistent"
        }
      }
    }
  ]
}    

IAM ロールにインラインポリシーを埋め込む

作成した IAM ロールのインラインポリシーを追加します.ドキュメントの手順に沿って最終的に以下のポリシーを作成できていれば OK です.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "workspaces:Stream",
            "Resource": "arn:aws:workspaces:ap-northeast-1:[AWS アカウント番号]:directory/[AD Connector のディレクトリ ID]",
            "Condition": {
                "StringEquals": {
                    "workspaces:userId": "${saml:sub}"
                }
            }
        }
    ]
}

SAML 認証レスポンスのアサーションを作成する

次に認証レスポンスの中に Microsoft EntraID が AWS に送信する SAML 属性としての情報を設定します.次の4点をシングルサインオンのページの属性とクレームセクションで指定します.

  • 一意のユーザー識別子 (名前 ID): user.mailnickname
  • https://aws.amazon.com/SAML/Attributes/PrincipalTag:Email : user.email
  • https://aws.amazon.com/SAML/Attributes/Role : arn:aws:iam::ACCOUNTNUMBER:role/ROLENAME,arn:aws:iam::ACCOUNTNUMBER:saml-provider/PROVIDERNAME
  • https://aws.amazon.com/SAML/Attributes/RoleSessionName : user.mailnickname

設定完了すると,以下の画像のような設定になります.

フェデレーションのリレーステートを設定する

Microsoft EntraID を使用した WorkSpaces ディレクトリのリレーステート URL を指すようにフェデレーションのリレーステートを設定します.https://relay-state-region-endpoint/sso-idp?registrationCode=registration-code 形式で指定する必要があるので,東京リージョンで設定する場合は以下のような指定になります.

設定後の URL

WorkSpaces ディレクトリで SAML 2.0 との統合を有効にする

Microsoft EntraID のエンタープライズアプリケーションで SAML 認証を通すユーザーを追加しておき, https://myapps.microsoft.com/ にアクセスして対象のエンタープライズアプリケーションのリンクをコピーしておきます.コピーした URL の signin 以降を切り取り, https://myapps.microsoft.com/signin/ の後ろに付与した URL を手元で作っておきます.ここから Workspaces ディレクトリで SAML との統合設定を進めます.ドキュメントに沿って最終的に画像のように設定が完了します.

Workspaces のログインで動作確認を行う

ここまでの設定が問題なければ,Workspaces クライアントから SAML 認証でログインできるようになるため動作確認を行います.

クライアントを起動して Continue to sign in to Workspaces をクリック

Open "WorkSpacesClient.macOS" をクリック

エンタープライズアプリケーションに追加したユーザーと前回記事の Active Directory に追加したログインユーザー名が一致しており,かつ Active Directory で設定したパスワードが一致してればログインが成功します.

まとめ

この記事では Workspaces へのログインで Microsoft EntraID SAML 認証を使う設定をまとめました.

Amazon Workspace を Microsoft EntraID の SAML 認証を行う~準備編~

タダです.

Amazon Workspaces(以下,Workspaces)を試す機会が久々に巡ってきて,Microsoft EntraID の SAML 認証を設定する事があったので2回に分けて書いていきます.この記事では,SAML 認証の前の準備編になります.

docs.aws.amazon.com

Workspaces と SAML との統合の準備で行うこと

まず,Workspaces と SAML との統合の準備で行うことをまとめますが,以下の2点です.

  1. EC2 Windows Server で Active Directory を設定する
  2. AD Connector を用意して EC2 にインストールした Active DirectoryMicrosoft EntraID と同期できるようにする

EC2 Windows Server で Active Directory を設定する

EC2 の起動部分はドキュメントに説明があるため,割愛します.余談になるのですが,接続する時にこれまでは RDP クライアントを使ってきたので今回も使おうとしたところ System Manager Fleet Manager があったので使ってみました.インバウンドでポートを開放しなくてもブラウザで OS にログインできちゃうのがすごかったので,もし使ったことがない方は是非試して欲しいです.EC2 が起動したら Active Directory のインストールと AD Connector が接続するためのサービスアカウントを追加します.既に様々な記事を公開している方がいるので,ここも割愛します.

参考記事

dev.classmethod.jp docs.aws.amazon.com

ここで記載しておくこととして,セキュリティグループのルールについて触れておきます.AD Connector と Workspaces が接続するためのポートを以下に記載します.インバウンドとアウトバウンドも同様のポートが開放されている必要があります.

プロトコル ポート番号 役割
TCP/UDP 53 DNS
TCP/UDP 88 Kerberos 認証
UDP 123 NTP
TCP 135 RPC
UDP 137-138 NBNS
TCP 139 SMB1
TCP/UDP 389 LDAP
TCP/UDP 445 SMB
TCP 1024 - 65535 LDAP

AD Connector で EC2 に接続する

AD Connector で EC2 on Active Directory に接続します.これは設定のウィザードに沿って進めば問題ないです.自分はポート開放がちゃんとできてなくてかなり詰まってしまったので,そこを誤らなければスムーズに接続できちゃうと思います.加えて AD Connector を Workspaces が使えるように登録します.AD Connector の設定時に指定したサブネットとは異なるサブネットを登録する必要がありますが,それ以外は特に詰まるところなく設定できました.

AD ConnectorとEC2が接続できていることと,Workspaces の登録が完了するとこの状態になる

ここまでで SAML 認証を行うための下準備が完了です.

まとめ

この記事では Microsoft EntraID のユーザーを同期するための AD Connector と同期先の EC2 on Active Directory を作成に関する内容をまとめました.次は SAML 認証の設定をまとめます.

Bytebase の SSO を Microsoft EntraID を使って設定する

タダです.

Bytebase のログイン方法は基本メールアドレスとパスワードによるログインになるのですが,Enteprise プランにすることで SSO を使えるようになります.トライアルで SSO を試してみたので備忘録にまとめます.

Bytebase の SSO 概要

Bytebase の SSOでは以下のプロトコルをサポートしています.この記事では Microsoft EntraID の OIDC を使って SSO を設定します.Bytebase のドキュメントに Microsoft EntaID の記載がないためこの記事にまとめておきます.

www.bytebase.com

Microsoft EntraIDのOIDCでSSOを設定する

EntraID 側の設定

予めエンタープライズアプリケーションを作っておきます.加えて,アプリの登録でAPIのアクセス許可で email を許可しておきます.リダイレクト URI として https://[Bytebase のドメイン]/oidc/callback を指定します.

Bytebase 側の設定

Bytebase 側で以下を設定します.最後に Test Connection を押して成功すれば,設定は完了です.

  • SSO 名: 任意の名前.
  • Issuerのendpoint: https://login.microsoftonline.com/[テナントID]/v2.0
  • ClientID: アプリケーションID
  • Client Secret: クライアントシークレットの値を指定
  • User information mapping : email を指定する

接続テストが成功すると Test connection succeed と表示される

まとめ

Bytebase の SSO 設定を Microsoft EntraID で設定を行っていたのでまとめました.

Bytebase の Terraform provider を試してみる

タダです.

Bytebase の設定は手動で設定していたのですが, Terraform のサポートされています.全ての設定をサポートされているわけでないですが,試した備忘録としてまとめていきます.

サポートされているリソースについて

Bytebase Terraform provider では次のリソースがサポートされています.

bytebase.cc

ローカル環境のプロジェクトを追加する

ローカルで Docker を立ち上げて新規のプロジェクトリソースを追加します.なお,最初は Sample project というのがあるだけです.

Docker を立ち上げた後 Terraform 用のサービスロールを追加し,ワークスペースDBA権限を持たせておきます.その後,Terraform 実行のためのサービスキーをコピーしておきます.

Docker の立ち上げコマンド

docker run --rm --init \
  --name bytebase \
  --publish 8080:8080 --pull always \
  --volume ~/.bytebase/data:/var/opt/bytebase \
  bytebase/bytebase:2.16.0

追加したサービスアカウント

Terraform provider を設定

以下のように provider 定義をしておきます.なお,必要なパラメータが①サービスアカウントのメールアドレス,②サービスアカウントのアクセスキー,③Bytebase の設定した外部 URLになります.

terraform {
  required_providers {
    bytebase = {
      source  = "bytebase/bytebase"
      version = "0.0.9"
    }
  }
}
provider "bytebase" {
  service_account = var.service_account
  service_key     = var.service_key
  url             = var.url
}

resource "bytebase_project" "first_my_project" {
  resource_id   = "first-my-project"
  title         = "Firest My project"
  key           = "FMP"
  workflow      = "UI"
  schema_change = "DDL"
}

プロジェクト初期化して, terraform apply で適用してみます.期待通りに First My project を追加できました.

❯ terraform init     

~中略~
Terraform has been successfully initialized!
~中略~

❯ terraform apply

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # bytebase_project.first_my_project will be created
  + resource "bytebase_project" "first_my_project" {
      + id            = (known after apply)
      + key           = "FMP"
      + resource_id   = "first-my-project"
      + schema_change = "DDL"
      + tenant_mode   = "TENANT_MODE_DISABLED"
      + title         = "Firest My project"
      + visibility    = "VISIBILITY_PUBLIC"
      + workflow      = "UI"
    }

Plan: 1 to add, 0 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

bytebase_project.first_my_project: Creating...
bytebase_project.first_my_project: Creation complete after 0s [id=projects/first-my-project]
╷
│ Warning: Project not exists
│ 
│   with bytebase_project.first_my_project,
│   on project.tf line 1, in resource "bytebase_project" "first_my_project":
│    1: resource "bytebase_project" "first_my_project" {
│ 
│ Project projects/first-my-project not exists, try to exec the create operation
╵

Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

terraform apply 実行後のプロジェクト一覧

まとめ

Bytebase の Terraform provider を使ってみたので使い方をまとめました.