C# & JavaScript

OneNote を新しいPCにインストール、設定しようとしていると… どうしても 0x803D0014 が発生してうまく同期ができない問題。

原因は不明ですが…とりあえず Killer Control Center を削除したらうまく動作しました。

今回は「macOS に MySQL クライアント をインストールする方法」についてまとめます。

概要

基本的には公式サイトからダウンロードしてインストールするだけです。 パス設定はなくても動作するはずですが、うまく動作しない場合は追加で対応します。

ダウンロード

公式サイトからMySQLサーバーをダウンロードします。 クライアントはサーバーに含まれるので一緒にダウンロードしてしまいます。

1. Oracleのダウンロードサイトへアクセス

   MySQL Community Downloads

2. Select Operating System で macOS を選択して DMG をダウンロード

   

インストール

インストール自体は指示に従って実行するだけです。

1. ダウンロードしたDMGファイルを開く

2. 中に含まれる pkg ファイルを開く

   

3. 実行してよいかの確認は「許可」を選択

   

4. 「はじめに」はそのまま「続ける」を選択

   

5. 「使用許諾契約」は内容を確認して「続ける」を選択

   

6. 確認ダイアログが出るので「同意する」を選択

   

7. 「インストールの種類」は特に何も設定を変更せず「インストール」を選択

   

8. インストール中…

   

9. 「Configure」では「Use Strong Password Encryption」を選択して「Next」

   

10. 次の「Configure」では root ユーザーパスワードを入力して「Finish」を選択

    

11. 「閉じる」で完了

    

パス設定

おそらく必要ないハズですが、 mysql を実行して動作しない（＝パスが通っていない）場合、パス設定を追加する必要があります。 「/usr/local/bin などすでにパスが通ったところへシンボリックリンクを配置する」か「パスを通す」かのどちらかになります。

方法１：/usr/local/bin などすでにパスが通ったところへシンボリックリンクを配置する

1. /usr/local/bin へ移動

   cd /usr/local/bin
   

2. シンボリックリンクを作成

   ln -s /usr/local/mysql-8.0.22-macos10.15-x86_64/bin/mysql ./mysql
   

方法２：パスを通す

1. ~/.zshrc へ以下を追記

   export PATH=$PATH:/usr/local/mysql-8.0.22-macos10.15-x86_64/bin
   

2. ターミナルを再起動

今回は「macOS に MySQL クライアント をインストールする方法」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

今回は「WindowsのSSHで鍵ファイルを任意の場所へ配置する方法」についてまとめます。

発生する事象

Windowsで鍵ファイルを使ったSSH接続をしようとすると以下のようなメッセージに遭遇することがあります。 ととえば、AWSのEC2に対してWindowsのPowerShellやコマンドプロンプトを使ってSSH接続しようとするようなケースです。

鍵ファイルを好きな場所に置きたいのだけれど特定フォルダ以外に配置すると権限が広すぎるというエラーで接続できない事象が発生します。 今回はこの事象を解消し、自分の好きな場所に鍵ファイルを置いたうえでコマンドを使ってSSH接続する方法をまとめます。

Warning: Permanently added '54.238.108.195' (ECDSA) to the list of known hosts.
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions for '.\\keypair.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key ".\\keypair.pem": bad permissions
ec2-user@54.238.108.195: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

解決策１：ユーザーフォルダ以下に置く

一番簡単な解決策は %HOMEPATH% (例： C:\Users\YOUR_NAME） 以下に配置することです。 %HOMEPATH% 以下であれば権限が制限されているので特にエラーにならず利用可能です。

解決策２：フォルダの権限を見直す

実際作業しているとどうしても D:\ など他のフォルダに配置したいこともあります。 以下では任意フォルダに対して鍵ファイルを配置してSSH接続を実現させる手順になります。

といってもやることは「鍵ファイルを配置したいフォルダの権限を見直す」だけになります。

1. 任意の場所にフォルダを作成

   

2. 作成したフォルダを右クリック「プロパティ」を選択

   

3. 「セキュリティ」タブへ移動

   

4. 「詳細設定」を選択

   

5. 「継承の無効化」を選択

   

6. 「このオブジェクトから継承されたアクセス許可をすべて削除します」を選択

   

7. 「OK」を選択

   

8. 「はい」を選択

   

9. 「編集」を選択

   

10. 「追加」を選択

    

11. 「選択するオブジェクト名を入力してください」に利用しているユーザー名を入力して「名前の確認」を選択

    

12. 自身の名前が選択されていることを確認して「OK」

    

13. 「OK」

    

14. 「フルコントロール」を選択して「OK」

    自分自身にフルコントロールが付いており、他のユーザーが存在しない状態（Admin含めて存在しない）になっていることを確認します。

    

ここまで出来たらあとは鍵ファイルを作成したフォルダへ移動してSSHするだけです。 きっと接続できるハズ！

今回は「WindowsのSSHで鍵ファイルを任意の場所へ配置する方法」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

今回は「複数アカウントを切り替えて利用するスイッチロール」についてまとめます。

概要

"開発" と "本番" でアカウントが違う

セキュリティ、監査上の対応やヒューマンエラーを防ぐといった目的から開発環境と本番環境で異なるアカウントを利用するといったケースがあります。 何も考えずただ普通にアカウント（IAMユーザー）を作っていくと次の図のような状態になります。

このような状態だと、複数のアカウントをいちいちログアウト/ログインを繰り返して切り替えることになり、作業がかなり面倒です。 また、ユーザー離着任のたびにIAMユーザーを消したり作ったりをそれぞれのアカウントに対して行うというのは漏れなどがありやや危険な気もします。

複数アカウントを切り替える "スイッチロール"

上記のような状態を解決する手段の１つがスイッチロールを使ったアカウント管理の集約です。

IAMユーザー自体はある1か所に集約し、他のアカウントへは適切なロールへスイッチさせて利用するという方法です。 ここで登場するのが「スイッチロール」と言う方法で、スイッチ先のロールのことを「AssumeRole」と呼びます。

今回はこの「スイッチロール（AssumeRole）」の作り方と使い方をまとめます。

設定

今回は以下のような単純化した環境での設定を行っていきます。 設定するのは「スイッチ先のロール」と「スイッチ元のポリシーおよびグループ/ユーザー」です。

スイッチ先

スイッチ先では信頼するスイッチ元のアカウントIDを指定した「IAMロール」を作成します。

ロール作成

スイッチ先のロール作成はマネジメントコンソール上から行ってみます。

1. IAMのロールから「ロールの作成」を選択

   

2. 「別のAWSアカウント」を選択

   

3. 「アカウントID」を入力して「次のステップ」を選択

   

   アカウントID

   スイッチ元のアカウントIDを入力

   外部IDが必須

   マネジメントコンソールを利用する場合、利用できないのでチェックしない。AWS CLI 利用の場合は使える。

   MFAが必須

   MFAの要否に応じてチェックを入れる

4. スイッチ先で利用させたいポリシーを選択して「次のステップ」を選択

   今回は管理権限を丸っと渡すので「AdministratorAccess」を選択。

   

5. スイッチ先のロールにタグを指定したい場合、タグ名を指定して「次のステップ」を選択

   

6. 「ロール名」を入力して「ロールの作成」を選択

   

スイッチ元

スイッチ元ではスイッチ先のIAMロールへアクセスできる「IAMポリシー」を作成し、そのポリシーを必要とするグループまたはユーザーにポリシーをアタッチします。

ポリシー作成

1. スイッチ元のIAMのポリシーから「ポリシーの作成」を選択

   

2. 「JSON」タブへ移動

   

3. ポリシーを直接記述で作成し、「ポリシーの確認」を選択

   

   {
       "Version": "2012-10-17",
       "Statement": [
           {
               "Effect": "Allow",
               "Action": "sts:AssumeRole",
               "Resource": "arn:aws:iam::<TargetAccountId>:role/<TargetAccountRoleName>"
           }
       ]
   }
   

   "TargetAccountID" にはスイッチ先のアカウントIDを入力、 "TargetAccountRoleName" はスイッチ先のロールとして作成したロール名を指定します。

4. 「名前」を設定して「ポリシーの作成」を選択

   

グループ/ユーザーへポリシー追加

作成したポリシーをあとは必要なグループやユーザーにつけてあげることで利用可能な状態になります。 ポリシーをグループやユーザーに付与するのはそのままなのでここでは割愛…。

利用

前述までの設定が終わっていればあとは利用方法です。 「ロールの切り替え」と「切り替えたロールから戻る」の2通りおさえればOKです。

ロールの切り替え

1. マネジメントコンソール右上のアカウント名を選択

   

2. 「ロールの切り替え」を選択

   

3. 初回の場合 "ロールの切り替え" が表示されるので「ロールの切り替え」を選択

   

4. 「アカウント」「ロール」を入力して「ロールの切り替え」を選択

   

   アカウント

   スイッチ先のアカウントIDを指定

   ロール

   スイッチ先のロール名を指定

   表示名

   表示名を任意の文字列で指定

5. 無事スイッチできればアカウント名が「表示名」に切り替わる

   

ロール利用の停止

1. マネジメントコンソール右上のアカウント名を選択

   

2. 「○○に戻る」を選択

   

今回は「複数アカウントを切り替えて利用する "スイッチロール"」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

今回は「Kinesis Data Firehose を使ってCloudWatch Logs にあるログを S3 へ転送する方法」についてまとめます。

概要

CloudWatch Logs の Log Group へ溜め込まれたログをS3へ流し込むための実装手順を見ていきます。 とりあえずログはすべてS3へまとめておくことができれば QuickSite や Athena への取り込みもできそうなので、その下準備になります。

今回は EC2 → CloudWatch Logs → Kinesis Data Firehose → S3 の流れを実装していきます。 作成するリソース類の全体は次のようなものになります。 実際に利用する際は適宜読み替え差し替えを行ってください。

上図の中で、今回は以下のリソースについてはすでに作成済みの前提で進めていきます。

• CloudWatch Logs ロググループ（＝転送元）
• S3バケット（＝転送先）

権限まわりの準備

CloudWatch Logs 用 IAMロール/ポリシー

CloudWatch Logs からは Kinesis Data Firehose への書き込みができる必要があるので、Firehose に対する書き込み権限を作っていきます。

sample-dev-firehose-write-iam-policy

まずは以下のようなIAMポリシーを作成します。

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "firehose:*"
      ],
      "Resource": [
        "arn:aws:firehose:<YOUR-REGION>:<YOUR-ACCOUNT-ID>:*"
      ]
    }
  ]
}

sample-dev-log-trans-firehose-iam-role

続いてIAMロールを…と行きたいのですが、マネジメントコンソール上から作成しようとすると「AWSサービス」に「CloudWatch Logs」が存在せず作成できません。 なので、いったん「EC2」などでIAMロールを作成し、作成したIAMロールの「信頼関係」タブから「信頼関係の編集」を選択して、以下の内容に書き換えます。

{
  "Statement": {
    "Effect": "Allow",
    "Principal": {
      "Service": "logs.<YOUR-REGION>.amazonaws.com"
    },
    "Action": "sts:AssumeRole"
  }
}

「信頼関係」が書き換われば、あとは「アクセス権限」から作成済みの「sample-dev-firehose-write-iam-policy」をアタッチします。

Kinesis Data Firehose 用 IAMロール/ポリシー

Kinesis Data Firehose はS3へ対する書き込みが必要なので、S3に対する書き込み権限を作っていきます。

sample-dev-s3-write-iam-policy

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:AbortMultipartUpload",
        "s3:GetBucketLocation",
        "s3:GetObject",
        "s3:ListBucket",
        "s3:ListBucketMultipartUploads",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::<YOUR-BUCKET-NAME>",
        "arn:aws:s3:::<YOUR-BUCKET-NAME>/*"
      ]
    }
  ]
}

sample-dev-log-trans-s3-iam-role

Kinesis Data Firehose のIAMロールはマネジメントコンソール上から作成可能なのでそんなに迷うこともありません。 作成する際は作成済み「sample-dev-s3-write-iam-policy」をアタッチします。

S3バケットポリシー

Kinesis Data Firehose にロール付与しただけだとS3バケットポリシーにはじかれるので、バケットポリシーも見直します。 Principalにはサービス指定できなさそうだったのでロールで指定します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<YOUR-ACCOUNT-ID>:role/<YOUR-FIREHOSE-ROLE>"
      },
      "Action": [
        "s3:AbortMultipartUpload",
        "s3:GetBucketLocation",
        "s3:GetObject",
        "s3:ListBucket",
        "s3:ListBucketMultipartUploads",
        "s3:PutObject"
      ],
      "Resource": [
        "arn:aws:s3:::<YOUR-BUCKET-NAME>",
        "arn:aws:s3:::<YOUR-BUCKET-NAME>/*"
      ]
    }
  ]
}

Kinesis Data Firehose の作成

1. New delivery stream

   インプット内容について設定していきます。

   

   Delivery stream name

   リソース名を指定します。今回は sample-dev-ec2-access-firehose 。

   Source

   インプット方法を指定します。 CloudWatch Logs の場合、 Direct PUT or other sources になります。

   Server-side encryption

   暗号化するかどうかの設定。今回は暗号化しないのでチェック無し。

2. Process records

   データ整形をするかどうかの設定を行っていきます。 今回は行わないのですべて Disabled になります。 もしデータ変換を行いたいのであればここで設定することができます。

   

3. Choose a destination

   アウトプット先について設定していきます。 今回はS3へアウトプットしていくのでS3に関する設定です。

   

   Destination

   「Amazon S3」を選択します。

   S3 bucket

   保存先バケット名を指定します。 ログは1つのバケットに集約したいのでログ用バケット「sample-dev-log-bucket」を指定します。

   S3 prefix

   正常に取り込む場合の保管先フォルダ名を指定します。 …正しくは保管先キー名のプリフィックス指定です。 他のログと区別がつくように保管先パスを指定します。

   S3 error prefix

   エラー発生時のエラーログ保管先プリフィックス名を指定します。

4. Configure settings

   その他オプションを設定していきます。

   

   S3 buffer conditions

   FirehoseはStreamと違ってバッファをとるのでその容量と期間を指定します。

   S3 compression and encryption

   圧縮と暗号化の設定です。 CloudWatch Logs はもともと圧縮された状態で転送されてくるので、改めて圧縮する必要はありません。 暗号化は必要に応じて設定します。 今回はどちらも利用しないので Disabled を指定します。

   Error logging

   エラーログを保存するかどうかの設定です。 保存先の設定と離れているので少しわかりづらいですが。。

   Permissions

   IAMロールを指定します。 あらかじめ作成済みなので作成したIAMロール「sample-dev-log-trans-s3-iam-role」を指定します。

5. Review

   最終確認。設定内容を確認して問題なければ「Create delivery stream」で作成します。

   

CloudWatch Logs のサブスクリプションへ登録

残念ながらマネジメントコンソール上から CloudWatch Logs のロググループに Kinesis Data Firehose をサブスクリプションとして追加することができません。 AWS CLI を使ってコマンドから接続します。

以下のコマンドを実行して CloudWatch Logs の ロググループ に Kinesis Data Firehose のサブスクリプションを追加します。

aws logs put-subscription-filter \
    --log-group-name "<LOG_GROUP_NAME>" \
    --filter-name "<SUBSCRIPTION_FILTER_NAME>" \
    --filter-pattern "<SUBSCRIPTION_FILTER_PATTERN>" \
    --destination-arn "arn:aws:firehose:<YOUR_REGION>:<YOUR_ACCOUNT_ID>:deliverystream/<FIREHOSE_NAME>" \
    --role-arn "arn:aws:iam::<YOUR_ACCOUNT_ID>:role/<CWL_IAM_ROLE_NAME>

PowerShell の複数行指定で利用する行末文字は "`"(バックティック) で、 コマンドプロンプトで利用する行末文字は "^"(ハット) です。

ちなみに…なぜか PowerShell だと filter-pattern に空文字（ "" ）指定が正しく認識されず。。 コマンドプロンプトだと正しく認識されました。

まとめ

CloudWatch Logs のロググループに入ったログを Kinesis Data Firehose を使って S3 へ転送する方法を見ていきました。 残念ながらすべてをマネジメントコンソール上からすることはかなわず。。 ところどころ手動で対応する必要がある点が注意点です。

テスト実行したいときはEC2に対してロググループへ出力される操作をしてみることになります。 …今回は具体的な内容に触れていませんが。。

Kinesis Data Firehose より後ろであれば、 Kinesis Data Firehose にサンプルデータ出力のテストコマンド実行ができるのでそちらを試してみるのもアリかと思います。

今回は「Kinesis Data Firehose を使ってCloudWatch Logs にあるログを S3 へ転送する方法」についてまとめました。 参考になったでしょうか？ 本記事がお役に立っていると嬉しいです！！

参考記事

• CCI Tech Blog - Kinesis Firehoseを使ってCloudWatch Logをs3へ出力してみた
• aws - 例 3: Amazon Kinesis Data Firehose のサブスクリプションフィルタ