エンジニャーリング

技術ときどきネコ

AWSのACMで作ったプライベート認証局から取得したプライベートキーからパスフレーズを抜く

通常の ACM (AWS Certificate Manager) で取得した Public な SSL/TLS証明書は、Private Key のダウンロードができません。

そこで、AWSACM (AWS Certificate Manager) で PrivateCA をたてて、Private な SSL/TLS証明書を発行し、この PrivateCA で発行した証明書から Private Key のダウンロードをすることにした。

作った証明書
f:id:taiyakikuroann:20210718144013p:plain

エクスポートを選択
f:id:taiyakikuroann:20210718144026p:plain

ここでパスフレーズを設定
f:id:taiyakikuroann:20210718144034p:plain

ダウンロードする
f:id:taiyakikuroann:20210718144046p:plain

証明書をクラインと証明書として使いたい場合にプログラムに組み込むとき、このダウンロードした Private Key はパスフレーズで保護されていて、使い勝手が悪い。
curlの場合はオプションでパスフレーズを渡せばそのまま使えるが、そのままcurlを叩くのもちょっと違う。

そこで、opensslコマンドを使って、このパスフレーズを抜いた形で保存し直す。

openssl rsa -in private.key -out private_no_pass.key -passin pass:[指定したパスフレーズ]

private_no_pass.key というパスフレーズが解除されたプライベートキーが作成できた。

ECSなどを使う場合、CodeBuildなどでビルド中に非公開のS3バケットから取得してパスフレーズを解除して取り込むなどの処理を追加すれば、よりセキュアな形でのPrivate Keyの管理ができて良いかと思います。

API Gateway + Lambda で403エラーが出て困った話

API Gateway を private に配置して、VPCエンドポイントからのアクセスを試みた。

タイムアウトした。
うむうむ、エンドポイントに設置したSGだなとインバウンドをセットして接続したところ、今度は403エラーに。

これは権限周りの設定のエラーになるので、resouce policy もセットして接続を試みた。

うん、403エラー。何故だ?!
調べても調べても resouce policy にセットしたら OK だと書かれてる。
以前設置したAPI Gatewayの設定を見ても同じような設定になっていて何ら問題はなさそう。

はて・・・どこの設定に抜けがあるのか??

とうとう英語のページにも手を出して調査を続ける。
そこにはこんな記載が。

if you update the resource policy after the API is created, you’ll need to deploy the API to propagate the changes after you’ve attached the updated policy.

APIの作成後にリソースポリシーを更新する場合は、更新されたポリシーを添付した後で変更を反映するためにAPIデプロイする必要があります

なん・・・だ・・・と・・・?!デプロイ?!!!

はい、デプロイ忘れてました。。。
API Gateway あまり使わないので思いつきもしなかった。
公開系に反映するのにはデプロイが必要なのです。

サクッとデプロイしたら難なく通りましたとさ。
2hくらい無駄にしてしまった。
Terraform で自動更新できるようにセットしたからもう忘れない(はず)

sedにはまる

CodeDeployを使っていてhookで動くシェルの中で設定ファイルを作っているところがあるのだが、production環境を設置してみたところ、sedで変な置き換わり方してた。
staging環境では起こらないのに・・・

例えば・・・

DATABASE_URL="mysql://userA:passwordA@localhost:3306/sample"
 ↓
DATABASE_URL="mysql://userB:passwordB@[mysqlのエンドポイント]:3306/sample"

のように変えたいところがこのようなことになっていた。

DATABASE_URL="mysql://user:passDATABASE_URL="mysql://user:password@localhost:3306/sample"word@[mysqlのエンドポイント]:3306/sample"

なぜゆえに?

どうもpassとwordの間に何かがあると思い、元のパスワードを確認すると & が入ってる!!!
pass&wordのところの & がどうやら元の文字列に置き換わってしまったらしい。
これはsedコマンドの使い方の問題っぽいから調べてみたところこのような記載が。

置換後の文字列に & を指定するとマッチした文字列の部分が出力され、
, ... を指定するとマッチした文字列のうち正規表現内でカッコでグルーピングされた部分が出力される。

ちなみに & をそのまま使うようなやり方もないので、仕方なくパスワードから & を外すことにした。
& がなければ無事に置換することができました。
パスワードに記号使うのも考えものだな。

セッションマネージャーのポートフォワーディング(続編)

前の記事でポートフォーワーディングについて説明した taiyakikuroann.hatenablog.com

のですが、このやり方だと複数アカウントを扱う場合にすごくやりづらい。
悩みの種だったのですが、良さげな解消できそうな方法を見つけた!
ポートフォーワーディング自体の設定を ~/.ssh/config に書いてしまおうってことでやってみた。

~/.ssh/config にこのようにポートフォーワーディングの設定を書く

Host example_tunnel 
  HostName       i-xxxxxxxxxxxx
  User           ec2-user
  LocalForward   9999 [RDSのエンドポイント]:3306
  ProxyCommand   sh -c "aws --profile=example1 ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"
  IdentityFile   [鍵ファイルを置いたところのパス]

HostNameにはインスタンスのIDを指定する
LocalForwardのポートとか転送先は用途に応じて変更する
ProxyCommandの--profile=example1はAWSのプロファイル名を指定

接続するときはこれでOK!

% ssh example_tunnel

サクッとできた。
この設定をアカウント毎に追加すれば複数アカウントでも管理可能!
前回の書き方だと書き直しが発生するので、この使い方のほうがおすすめ。

wena3 初めての改造

wena3のレザーを持ってます。
が、、、夏はレザーが暑い!ので、ベルト部分を変えてみた。

[材料]

  • wena
  • 爪楊枝
  • ベルト用に使う布製の幅15mmの帯みたいなやつ(100円ショップで見つけた)
    本当は18mmが適切だと思うけどなかった。 f:id:taiyakikuroann:20210626231107j:plain

[作り方]
帯みたいなやつを手首のサイズよりも長めに裁断する。
裁断したままだとほつれるので、切断面をライターでちょっとだけ炙る(燃やさないでね)

爪楊枝で帯みたいなやつに2箇所穴を開ける(端と端の丁度いい場所に開ける)
レザーベルトと同じような付け方でセットする。
仕上がりこんな感じ。 f:id:taiyakikuroann:20210626233129j:plain

15mmでも全然いけそうな感じ。(本当は18mmが正しい)
でも、レザーに比べて高級感はナッシング・・・
この辺は合わせる時計によるかな。スポーツタイプならこのままで全然OK。

とりあえず涼しくはなりました。ベトベトもしなくなりました。
寝てる間に無意識に外してしまうこともないでしょう。睡眠トラックもきっとちゃんと取れるに違いない。
自分の好きなレザーで作るもよし、布製の帯みたいなやつで作るもよし、可能性を感じます。
sonyさんも替えのベルトだけでなく、ベルトの種類を増やして欲しいものです。
というか、バックルの部分が同じならメタル⇄レザー⇄ラバーの互換くらいは付けて欲しかったな〜・・・
今後に期待。

余談ですが、歯医者にいった時に生体認証のストレス値がめっちゃ高かった。
生体認証はビミョーって意見が多いんですが、割と合ってる?とか思いました。

wena3 を買いました

スマートウォッチ何使ってますか?
やっぱりApple Watchですか?

私はwena2 activeを使ってました。
もともとAndroid使ってて(当時良さげな)ペアリングできるスマートウォッチがなかったのと、ヘッド部分が好きなものに交換可能できるのも魅力で愛用し始めてはや2年ほど経ちました。
このまま使い続けるのかと思いきや、AppleWatch使ってないんですか?という質問から調べてみたら、新しいバージョンがリリースされてることに気づいてしまって、迷いに迷った(Apple Watchとも迷ったんだが)結果購入してしまいました。

購入ポイントとしてはこんな感じ

  • Suicaが使える←ポイント!wena2じゃ使えず、これがなければ、ほんと買い換えるつもりはなかった(地元の交通系ICにポイントが付かなくなったのも大きい。これはコロナのせい)
  • ヘッドが変えられる
  • 充電したら1週間もつ(AppleWatchは良くて2日ぐらいらしい)
  • スマートウォッチが嫌な時はウェアラブルとしても使える

まぁ、Apple Watchの方が性能が良いのだが、逆に良すぎるので余計だと感じる部分もあって(使ったことないから嘘だったらごめん)心的な負担にになりそうだったので、なんとなく欲しいものどりができそうだと思ったのが一番大きいかな。
なので、他の比較とかはできないですがwena3の良かったところと悪かったところを書き記してます。 ちなみに、メタル、レザー、ラバータイプのうち、私はレザータイプを購入しました。

良かったところ

  • Suicaが使えた
    ドキドキしながら改札を通ったのですが、見事にタッチ&ゴーできた!
    iosSuica使っていた頃は、ダブルクリックした後にマスクのせいでFace認証できなくて毎回パスコード認証してました。
    マスクしてなかったら使いやすかったんだろうけど、このちょっとしたことが耐えられなかった。最新のアップデートではAppleWatchをつけてたらパスコードを入力しなくても使えるようです。 AppleWatchかざせばそのままタッチ&ゴーできるかも。
    めんどくささから解放されたので、とりあえずよし!

  • iDが使えた iosで使う場合はおサイフリンクを使ってiDの支払いが可能!
    これはwenaに限らずのことだが、自分が使いたい機能でおサイフリンクで使えるのは便利。(おサイフリンク自体は使える機能が限定されるので微妙かも)
    私の場合は、主流がSuicaとiDだったのが使いやすいポイントだった。

  • 好きなヘッドが付けられる
    アナログの好きなヘッドが付けられる。
    男性用の時計が主流。女性が使いたい場合は考えた方が良いがやり方はありそう。

  • Alexa が使える Alexaが簡単な質問に答えてくれる

  • 充電が長持ち
    Max充電して1週間ぐらいは持つから週末充電すればいい。とても楽である。

悪かったところ

  • ヘッドをつける時のコネクターが難しい
    ヘッド(時計部分)に合わせて専用の部品が必要なのだが、知識が無い者にとってはこれがとても難しい。
    コネクト部分の幅が何ミリとかによって部品が変わってくるので、適切なものを選ぶところが至難!
    自分でカスタマイズできると思えば楽しい分野ではあるが、部品代がかさむのも微妙ポイント。

  • レザータイプだと、ヘッド(時計)部分の入れ替えがやりづらい
    最初の付属部品は22mmのものです。たまたま持ってる時計も22mmで丁度良い感じだが、気分によってヘッドを交換したい時にベルト幅とヘッド幅が合ってなかったりしてカスタマイズがやりづらい感が。その日の気分による着せ替えがこのままだとできない。
    →アイデアでなんとかなりそう

  • メタル⇄レザー⇄ラバーの入れ替えができない
    主要なところはバックルになるので、ベルトになる部品を互換性にして入れ替えできてもええやん・・・って思ってしまう。

  • 単体で音楽が聴けない
    特に欲してない。やりたければios端末でいいや。

書いてて気づいたんだが、全部のっけが欲しいわけではなく SuicaiDヘッド とが欲しかった!という結論。
数日使ってみて今のところ満足している。