omuronの備忘録

個人的な備忘録

「第二回 AWSマルチアカウント事例祭り」 #ama_fes02 受講メモ

zozotech-inc.connpass.com

昨年9月以来の「AWSマルチアカウント事例祭り」です。
前回の受講メモは こちら

マルチアカウントでのIAMユーザ把握と可視化 IAMユーザー棚卸しへの取り組み

講師: 株式会社ZOZOテクノロジーズ CTO室 / 技術開発本部 SRE部 テックリード 光野 達朗(@kotatsu360)さん

speakerdeck.com

  • 組織全体の AWS に関する話
    • マルチアカウントでも IAM ユーザーの棚卸しはできる
    • IAM ユーザーを把握、Slack へ通知
    • Azure AD で SSO
  • IAM ユーザーの問題
    • アクセストークンの期限がない
    • AWS SSO があれば IAM ユーザーを使う必要はない
  • どうやって把握するか?
    • コンソールのパスワードをもたないユーザーを取りたい
    • 「認証情報レポート」を活用
      • IAM ユーザーと認証情報のステータス一覧を CSV で取得できる
  • 取得データの加工するために活躍した AWS サービス
    • CFn Service Managed StackSets
    • Amazon Athena
      • 日付をファイル名につけてスキャンを減らす工夫
    • Amazon QuickSight
      • 可視化を社内で展開
    • Lambda から Organizations を叩いてレポートを叩いて S3 に保存
  • 今後
  • まとめ
    • AWS 全体で IAM ユーザーを最小限にしたかった
    • 認証情報レポートでアカウント単位の IAM ユーザーを取得
    • CFn StackSets / Athena / QuickSight で可視化

QA

  • IAMユーザを作らざるを得ないケースもあるかと思いますが、どのようにコントロールされていますか?
    • アクセストークン利用するためのユーザーなどは作る必要はある
    • AWS Config で検知して、ヒアリングする形を考えている
    • 必要なものを必要なときに作る運用
  • だいたいどれくらいのIAMユーザがいました?
    • 3XX ぐらいいた
    • SOO を使いだして 100 を切るぐらいになった
    • 1割の 30 を目標に目指すは 0
  • IAMの最終利用日時だけではIAMの必要性判断には情報不足すると思いますが、IAMの利用状況の把握は結局1つ1つ確認する以外に何かあるのでしょうか?まずは使っていないIAMを削除するという方針でしょうか?
    • アクセストークンの有無と最終利用日を目安にする
    • SSO 利用で不要になったユーザーも多い
    • ログインのパスワードを無効化して調査をした
    • IAM ユーザーを消すことで負の運用作用になると本末転倒なので注意した
  • SSO の権限セット
    • Admin と PowerUser と ReadOnly とわける
    • + Billing があれば対応
  • 認証情報レポートの情報そのものはAPIで取得できない?
    • おそらく aws iam describe-user で取れる
    • API で全員をとるのは煩雑なので API で取得は選択肢としていれてない
    • 認証情報レポート一本で処理をするようにした
  • アカウントIDからアカウント名を取得する際の「organizations:DescribeAccount」は、メンバーアカウントから実行してますでしょうか?
    • Yes
    • Lambda から Organizations の API を叩いて取得
    • Organization 側に assume role を作って権限移譲して動くようにしている
  • IAMユーザーを使用している理由で多かった理由を知りたいです。
    • マネコンにログインするため
  • 東京リージョンに AWS SSO が来る前はどのような運用をしていましたか?

AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと

講師: ニフティ株式会社 基幹システムグループ 石川 貴之さん

www.slideshare.net

  • 管理者方針
    • Admin 権限をあたえる(移譲)
    • 本当にやってほしくないものだけ禁止(予防)
    • 危険な行為や設定は通知(検知&通知)
  • 導入前にきめたもの
    • あとから変更しづらいものはしっかり
      • AWS アカウント粒度
      • コンソールログインアカウント
        • IDaaS 経由でのログイン
      • マルチアカウトへの設定配布
    • あとから変更しやすいもの、運用改善できるもの
      • AWS アカウント新規作成と初期設定の自動化
        • CFn StackSets + 一部 Lambda&AssumeRole
  • 運用を始めたあとにセキュリティの追加要素
    • ConfigRule を値下げのタイミングで追加
    • 通知系
      • アラートが多すぎて通知を見なくならないように注意
      • 通知に危険性と対処法のリンクを追加
    • root の MFA
  • まとめ
    • 利用者の成長を阻害しないセキュリティ
    • はじめは速度優先、利用状況にあわせてセキュリティ追加
    • ROI を考えて導入や移行を決める

QA

  • 二フクラとAWSをどう使い分けてるか知りたいです
    • 得分野が違う
    • IO 使うものはニフクラが安いのでそちらを使う
  • 100を超えるAWSアカウントは、結局どのような粒度で作成されているのでしょうか?
    • 1サービス1システムに開発と本番は作る
    • サービス単位で分けるかは担当者に任せる
  • セキュリティ通知されたものに対して実際にアクションされている割合はどんな感じでしょうか?
    • 測っていない
    • 緊急性の高いものはイシュー管理
  • GuardDutyの結果もリスクの高いものだけ基幹チーム側でケアされてる感じでしょうか?その他は利用部門側に任せる感じでしょうか?
    • レベルが GuardDuty できまっているので High だけケア
  • controltowerはlamding zoneを有効化していないだけでしょうか?
    • 全く使ってない
    • 思想は参考にしている
  • 二フクラもマルチアカウントできるの?
    • 定義によるが複数は作れる
    • 横断してはできないかも?
  • マルチアカウントでのコスト管理についてもお時間があれば聞きたいです。例えば、RIやSPの購入や管理方針について。
    • 各アカウントで RI や SP を買う
      • ベストプラクティスを伝えて担当者任せ
    • マスターで買うとどこがどれぐらい使ったか計算が必要なため
  • stacksetsの内容を更新する時は、各利用部門にメンテ通知を出して一斉にやられている感じでしょうか?
    • メンテ用の Slack チャンネルで告知して実行
      • 費用や通知がわかるようにメンテページを作って告知

セキュリティインシデントを乗り越えるために行ったマルチアカウントでの取り組みについて

講師: Classi株式会社 プロダクト開発部 大南 賢亮さん

speakerdeck.com

  • セキュリティインシデントについて
    • 不正アクセスでサービス停止
    • ユーザー情報流出の可能性
      • 外部サイトで流出情報の確認
  • Organizations Before
    • OU/SCP を利用していない
    • Production アカウントが Organization 管理アカウント
    • Bastion アカウントを開発者がサンドボックス利用
  • やったこと
    • 管理アカウント切り替え
      • 新規作成して移動
    • OU 設計と配置
      • Foudational OU
        • Workloads OU
          • Prod OU
          • SDLS OU
        • Infra OU
        • PolicyStaging OU
      • Meintenace OU
      • Suspended OU
  • ID とアクセス管理
    • G Suite SAML 連携にてマネコンにアクセス
      • AWS SSO へ移行
      • アクセスキー管理不要に
    • Bastion アカウントから Switch Role
      • Switch Role 先の設定ミスで入り放題になったことあり
  • ガードレール
    • リージョン制限
    • 監査操作の制限
    • インフラは共通基盤操作制限
    • Prodでの重要操作の制限など
  • 今後
    • ガードレールのチューニング
    • ロギングとモニタリングの強化
  • まとめ
    • マルチアカウント構成を活かす形で対策
    • AWS SSO 利用でアカウント管理コスト下げてSecureに
    • ガードレールの導入

QA

  • RoleとSCPの管理を行うのは負荷にならなかったでしょうか?
    • それほど負荷にならなかった
  • 予防的ガードレールとしてPermission Boundary使っていますでしょうか?
    • 使ってない
  • 本題ではないですがAAD × GSuiteという構成が気になりました。AADからAWSへのSSOは出来なかったのでしょうか。
    • もともと AWS SSO できる前からこの構成だった
  • Config Ruleは現在どの様なものを設定して運用しているのでしょうか?カスタムルールも運用してますか?どの様なルールを使われていますか?
    • まだあまりチューニングできてない
    • これでもかなり引っかかる
  • 他のセキュリティ系のサービスで導入を検討しているものはありますか?
    • IAM AccessAnalyzer
    • コンテナではアクア
  • ConfigRuleなどの検知設定のチューニング時の基準みたいなものはありますか? 必要/不要の判断の際に参考にするバックグラウンドとなるセキュリティポリシーが存在するのでしょうか
    • 基準を策定中
    • セキュリティ対策の優先順位としてID管理、アカウント管理、アクセス管理
    • ロギング、モニタリングのあとにポリシーをつめたい
  • SCPはAWS導入の初期から実施されましたでしょうか?AWSを運用した途中からSCPを入れるとしたら苦労しましたか?
    • 6年ぐらい AWS を運用していた
    • 後からは大変だったがインシデントがあったのでやる必要があった
    • 計画メンテナンスを入れて対応した
  • SSOユーザのアカウントへの紐づけ情報の棚卸は実施されていますでしょうか?

所感

複数アカウントを管理していますが、Organizations はうまいこと活用できてません。
新規 AWS アカウント作成時の CFn テンプレートは準備してますが、StackSets にもせず順番にスタックを作っている状況。
やったほうがいいのはわかっているのですが、そんなにも数が多くないと綺麗に作り直すモチベーションがでなくて難しいですね。

懇親会は Clubhouse という今どきの形です!
ということでこちらを聞きに移動します。

游ゴシックの name テーブル確認

はじめに

【リアルに9割の人が気づいていない「游ゴシック」の話】が話題になってますね。

togetter.com

なぜ、この現象がおきるか確認します。

フォントの仕様

フォントの切り替え時の振る舞いは、フォント内部の name テーブルの設定に依存します。
name テーブルの仕様は こちら

Name ID 1 が "Font Family name" です。
Name ID 2 が "Font Subfamily name" です。

Windows では "Font Family name" が同じ場合に、同一フォントファミリーとして認識します。

游ゴシックの値

実際にフォントの中に設定されている値を見てみます。

フォント Name ID 1 Name ID 2
YUGOTHL.TTC Yu Gothic Light Regular
YUGOTHR.TTC Yu Gothic Regular
YUGOTHM.TTC Yu Gothic Medium Regular
YUGOTHB.TTC Yu Gothic Bold

設定されている値から分かる通り、 YUGOTHR.TTC(游ゴシックR)フォントと YUGOTHB.TTC(游ゴシックB)フォントは、同一の Yu Gothic(游ゴシック)ファミリーになっております。
そのため、Word などの Bold ボタンを利用することにより、 RegularBold のフォントを切り替えることができます。

一方、 YUGOTHL.TTC(游ゴシックL)フォントは、ファミリー名にウェイトも含まれた形の Yu Gothic Light という名前になっております。
そのため、Bold ボタン押下時には、 Yu Gothic Light ファミリーの Bold ウェイトが存在しないため、偽ボールド( Fake Bold )になる振る舞いをします。
YUGOTHM.TTC(游ゴシックM) も同様に、切り替え先の Bold は存在しません。

さいごに

DTP 向け書体を Windows で利用すると、気づかずに偽ボールドを使うことがあるので、ちょっと気をつける必要がありそうです。
とは言ってもなかなか気が付きにくいから難しいよなぁ。

(小ネタ) ECR リポジトリが存在しないときにワンライナーで作成する

CodeBuildECR に push しようとしたときにエラーが発生しました。

[Container] 2021/01/21 09:04:15 Running command docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/***:$BRANCH_NAME
The push refers to repository [123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/***]
20e0a6dcff7f: Preparing
029c325415ee: Waiting
name unknown: The repository with name '***' does not exist in the registry with id '123456789012'

[Container] 2021/01/21 02:04:15 Command did not exit successfully docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/***:$BRANCH_NAME exit status 1
[Container] 2021/01/21 09:04:15 Phase complete: POST_BUILD State: FAILED
[Container] 2021/01/21 09:04:15 Phase context status code: COMMAND_EXECUTION_ERROR Message: Error while executing command: docker push 123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/***:$BRANCH_NAME. Reason: exit status 1

リポジトリが存在しないエラーが発生。

あれ? ECR リポジトリって事前作成必要だっけ?
なくても勝手に作ってくれなかったかな。
以前同じような実装したときに、ECR にリポジトを事前作成した記憶がまったくない。
とりあえずリポジトリが存在しない場合に作成するように変更することにしました。

CodeBuild の AssumeRole に権限を付与して

- ecr:DescribeRepositories
- ecr:CreateRepository

docker push 前に存在確認してなければ作成。

aws ecr describe-repositories --repository-names $REPOSITORY_NAME || aws ecr create-repository --repository-name $REPOSITORY_NAME
docker push $REPOSITORY_NAME:$BRANCH_NAME

docker push して、存在しなければ勝手に作ってくれると思ってたんですが...
これは私の勘違いだったんでしょうか?

「JAWS-UG朝会 #17」 #jawsug_asa 受講メモ

jawsug-asa.connpass.com

早起きは三文の徳の朝会です。
今日のラジオ体操は事前収録済みのムービーでした。

セッション① 年頭 JAWS-UG 振り返り

講師:アマゾン ウェブ サービス ジャパン株式会社 沼口 繁さん

www.slideshare.net

JAWS-UG

  • 歴史
    • 2006 米国 S3/EC2 サービス開始
    • 2009 AWS 日本法人
    • 2010/02/23 先行ユーザー100人を集めて第0回開催
    • 2011/03/02 東京リージョン開設
  • アイコン
    • 浜松支部が初めてカスタマイズロゴ作成
      • それから色々なサメの種類が増えていった
      • 海外受けが良いらしい
  • 3つの特徴
    • オフラインのIT勉強会と懇親会
    • アウトプットカルチャー
    • 自走するコミュニティー
  • 疎結合組織をつなげるいいリズム(間で re:Cap)
    • 06月 AWS Summi
    • 10月 JAWS FESTA
    • 12月 AWS re:Invent
    • 03月 JAWS DAYS
  • JAWS DAYS 2021
    • 2021/03/20 オンラインで開催!

re:Inventについてみんなで雑談

  • re:Invent 新機能で衝撃的だったもの
    • S3 が結果整合性から強い整合性になった
      • Googleは数年前からでておりどうやってできる?
      • 参考 Twitter
    • Lambda の1ms課金
    • mac instance
    • EBS GP3 安くなってパフォーマンス向上
    • CloudShell ユーザー権限で CLI そのまま動く(ので注意)
  • CloudShell を踏み台にできるようになる?
    • 使い捨てするコンテナで生活できるか?

所感

re:Invent で衝撃的だったものに「毎日 re:Capしてる亀田さん」というのがでてウケました。
個人的には、トラックで MacMini が大量に運ばれたのが笑撃的だった。

オンラインでの雑談は難しいですね。
先日参加した勉強会でも最後は話すことができましたが、ovice.in 使ったからこそというのがあったと思う。
オンラインで交流するのはまだまだ課題が多そうと感じました。

Tech-on MeetUp Online#04「いまエンタープライズのエンジニアが押さえておきたい認証認可、IDaaS」 #TechOn東京 受講メモ

techplay.jp

「さて、今夜お話しいただくのは認証・認可・IDaaSです。」
という内容で、実装は自力ですべきでないけど知っておきたい認証認可と IDaaS の話です。

「IDaaS を利用すべき理由とエンジニアが押さえておくべきポイント」

講師:日本電気株式会社・釜山 公徳さん

ノンテクニカルサイド

  • エンジニアもノンテクニカルサイドも抑える必要あり
  • NIST, ISO, OpenID Foundation, FIDO Alliance は抑える
    • NIST SP800-63, ISO/IEC 24760-1
  • 身元確認(自己申告、身分証)、当人確認(ID/Password, 生体認証)
    • 本人確認(身元+当人)
  • IDaaS 市場
  • 古くは SAML 認証
  • OpenID Foundation の参加で規格
    • OAuth2.0 : ID/Pass を使わなくてアプリ連携ができる
    • OpenID Coonect : OAuth2.0 を使ったユーザ認証、1つのプロトコルで多くの IdP とやり取り可能(利便性がある)
    • FAPI : Financial-grade API, 金融向けに利便性を高めた規格の策定中
    • CIBA : Client Initiated Backchannel Authentication, デカップルド・フロー
  • FIDO : モバイル生体認証、FIDO 仕様準拠がデファクト

テクニカルサイド

  • 認証: Authentication(AuthN)
    • リソースにアクセスする個人の身元確認
    • OpenID Coonect, SAML
  • 認可: Authorization(AuthZ)
    • 認証後アクセス権のレベルを確認するプロセス
    • OAuth
  • ID/Password が氾濫すると情報漏えいに繋がる
  • OneLogin ができること
    • アカウント管理
    • セキュリティ強化
      • アクセスコントロール
      • 多要素認証
        • 最も効果が高い
      • ログレポート
        • レポートを見るとASIS分析ができる
        • 課題解決できる、見ないと課題解決できない
  • Azure AD の認証方法
  • まとめ
    • ID 関連はビジネスサイドとテクニカルサイドの両サイド抑える
    • 複雑なのでガイドラインを活用

「Auth0とクラウドサービスを組み合わせて作るメディアコマースの開発事例」

講師:株式会社Serverless Operations 堀家 隆宏さん

IDaaS の採用の意味とメリット

  • 一昔前: DB にユーザー情報を保存して CRUD 操作
    • セキュリティ対策コスト, ユーザー管理コスト
    • 個人情報を扱う標準規格への準拠
  • これらを解決する昨今の IDaaS
    • セキュリティ、利便性、運用コスト
    • 一元管理して SAML で各種社内利用サービスへログイン
    • アプリ開発も IDaaS、OIDC/OAuth2.0 プロトコルが容易になる

Auth0

  • 認証認可の SaaS プラットフォーム
  • ソーシャルログインの導入が一瞬、GUI で設定するだけ
    • 自力実装すると数ヶ月かかる
  • Automatic Migration 機能により無停止で Auth0 移行可能
    • 再パスワード入力不要
  • CI/CD で本番テナント設定可能
    • YAML で設定可能なので出力してインポート

EC TOKION における実例

  • AWSWordPress
  • ログイン機能は WordPress
    • Auth0 と直接認証するのは WordPress のみ
    • Auth0 の WordPress プラグイン利用
      • 高機能でカスタマイズできるので本番で使える
    • Shopify の Multipass 機能を使って Shopify に引き継ぐ
    • WordPress と S3 ホスティングのログイン状態のやり取り
      • SSO の機能を使って実装
    • ログアウトしたら全サービスでログアウト状態にするのが大変
  • EC2 on WordPress を使っているのでメンテコストがかかる

AppSync での実装例

  • AppSync
    • GraphQL のバックエンドマネージドサービス
  • Shifter Headless
  • AppSync + Auth0
    • AppSync が OIDC に対応しているので Auth0 が簡単に使える
    • AppSync を BFF としてフロントからの認証を集約
      • ログイン状態の引き継ぎが不要
  • WordPress を Shifter にしているのでメンテコスト削減
    • AppSync の学習コストはいる

まとめ

  • Auth0 のような IDaaS を導入しないメリットはないので使う
  • TOKIO のような複数サービスだと状態管理がいる
  • AppSync のような BFF も検討

ガヤタイム

  • AWS のログはちゃんと見ておこう
    • 退職者がでたらすぐアクセス権消す
    • そもそも持っていけるものを持っていくことが悪いと思ってない場合もある
      • 文化や教育次第なところ
  • ログは開発者が作るもの
    • 100%信用できるか?ミスリードしないように。
    • Java のエラーが出た
      • 追っかけるとメモリが間欠故障してた...とか
  • 監査ログ10年残せ
    • 本当にいるのか?プロアクティブに動けるのか?
    • 法律のためでコストばかりかかる
  • ログが整形されているか?
    • hadoop で解析しようとしたけど整形されてなくて無理だった
    • awk で手動で整形...
      • ある程度整形したらエクセルに貼り付けてピボットテーブル
    • LogFormat は大事

所感

ovice.in というツール利用してのプレゼンでした。 バーチャルセミナー会場みたいな感じのツールが最近はやってますね。

メモを取りきれませんでしたが、金融のセキュリティの話を聞けたのが新鮮でした。 普段とは違うセキュリティ観点の話なので、やはりお金周りがメインの仕事だともう一つ大変なんですね。

Auth0 の実装が楽なのはそのとおりに感じてます。 自力実装に比べると本当に楽なんだけど、理解して使い始めるスタート地点のハードルはそこそこ高いと感じてます。 ゆえに理解を深めるために引き続き勉強がまだまだ続きそうです。

CodeBuild のビルドログが *** とマスクされる理由を調べた

事象

CodeBuild のビルドログにて正しく入れているつもりの情報が *** と表示されることがありました。

[Container] 2021/01/07 06:57:03 Running command make docker-build
DOCKER_BUILDKIT=1 docker image build --tag ***

BuildSpec をみても、環境変数をみても問題なさそうなのにログだけがおかしい。
このビルドログが出ているタイミングで、ビルドが失敗してしまったので、何らかの問題があるかと調査をしました。

結論

ビルドの失敗は別問題で、ログ上に情報が表示されてないだけでした。

公式ドキュメント

docs.aws.amazon.com

注記
機密情報を保護するために、CodeBuild ログでは次の情報が非表示になっています。

  • AWS アクセスキー ID。詳細については、AWS Identity and Access Management ユーザーガイドの「IAM ユーザーのアクセスキーの管理」を参照してください。
  • パラメータストアを使用して指定された文字列。詳細については、『Amazon EC2 Systems Manager ユーザーガイド』の「Systems Manager パラメータストア」および「Systems Manager パラメータストアコンソールのチュートリアル」を参照してください。
  • AWS Secrets Manager を使用して指定された文字列。詳細については、「キーの管理」を参照してください。

今回は、AWS Secrets Manager を利用して Docker Hub へログインしていました。
このときに利用しているユーザー名とビルド時に指定しているタグ名がたまたま同じだったため、非表示になりました。

まとめ

「Systems Manager パラメータストア」や「AWS Secrets Manager」を利用している場合は、その値を直接参照していないケースでもログが非表示になる可能性があるようです。
ログの表示が見えないだけなので、実際の動作は問題ありません。
直接利用している箇所だけがマスクされるわけじゃないことに注意したいと思います。

「AWS CloudShell おもしろ選手権」 #omoshiro_cloudshell 受講メモ

connpass.com

www.youtube.com

シェル芸は見ているだけで楽しいですね。
もっとシェルを使いこなしたいです。

本当だったらここに最高のキーノートがくるはずだった話

講師:トリ (@toricls) さん

  • クラスメソッドさんに相談したけど頼み方が悪かったのか失敗したとw
  • ホームディレクトリ配下は毎回消える。
    • .bashrcsudo npm install -g cowsay とか書いておくと自動で復旧させれる

LT1: CloudShell で SSM Agent を動かす

講師:so (@3socha) さん

SSM でつないだり、ssh でつないだりそんなことまでできたんか...

github.com

LT2: 禁止してみた

講師:SAKON (@sakon310) さん

speakerdeck.com

  • 他のクラウドサービスにはすでにある
    • ほかは Cloud Shell でスペース入る
  • いいところ
    • 端末キッティング不要
    • プロキシ穴あけいらない
    • マネコンIAM認証情報で動く
    • AL2 コンテナ 1GB 無料スペース
    • Safe Paste でオペミスも起きにくい
  • 便利すぎてガードレールが必要な雰囲気
    • 統制側からすると不安
    • 操作履歴が残らない
      • SSM だと残せる
  • 結果禁止した
    • IAM ポリシーから AWSCloudShellFullAccess 削除
  • セキュリティ上これがあればいい
    • 操作履歴を CloudWatch
    • 一括設定
    • 追加永続化ストレージ、EFSマウント

LT3: CloudShell でも開発したい! (ネタ)

講師:y-ohgi (@_y_ohgi) さん

開発したい話の予定が、開発したかったになったと。

speakerdeck.com

LT4: AWS初心者がCloudShellを使ってみた話

講師:amarelo(アマレロ) (@amarelo_n24) さん

speakerdeck.com

  • AWS CLI v2
  • 歯車アイコンから設定変えれる
    • 色、フォントサイズなど
  • 初心者でも使えた
    • 無料で使い込めるので色々やってみたい

LT5: CloudShellをIaC実行基盤として考えてみる

講師:ハマコー (@hamako9999) さん

dev.classmethod.jp

  • インフラをプロビジョニングするのは重大な権限が必要
  • 各リージョンで10個同時起動まで無料
    • 実質無料
  • IaC のコード
    • CodeCommit : IAM 権限で clone
    • GitHub : 認証めんどくさい、GitHub push で自動で S3 にコピーとか
      • homeは1G なので /tmp を利用
  • 実行ログをきちんと残す仕組みを構築
    • 実行権限や履歴をCloudTrailで管理

LT6: CloudShell内で動かしてるサービスを公開してみた

講師:しょーちゃん (@show_m001) さん

www2.slideshare.net

  • アイコンの位置とデザインは Azure (ry
  • ps ax で pid 1 をみるとコンテナとわかる
  • インバウンドは閉じている
    • ngrok で対応する
      • こじ開けることが可能

LT7: 狂気!AWS CloudShell細胞分裂

講師:ぐれさん😉 (@grethlen)

speakerdeck.com

  • tmux がデフォルトで入っている
    • 分割してもレイアウト崩れない
  • tmux と xpanes が使える
    • ssm は 40 ぐらいが限界
    • ojichat 100 いけた

f:id:omron:20201229165431p:plain

LT8: 何はともあれ、まず最初にやることといえばこれ

講師:KOMEDA Shinji (@komeda_shinji)

  • etckeeper
    • /etc にあるファイルをバージョン管理してくれる
  • CloudShell 制限
    • 20分でタイム・アウトする
    • /home は永続的、それ以外は非永続
    • /etc も初期化される
    • hostname, hosts は毎回変わる
  • yum install すると自動コミットされるようになる
    • daily の自動コミットはできないので適宜自分で
    • 変更履歴が残るので再現が楽になる

LT9: AWS CloudShellでLeaf Rogueを動かしてみる話(仮)

講師:フランドン畜舎内 ヨークシャイヤ (@furandon_pig) さん

furandon-pig.github.io

  • シェルさえあれば生きていける人も多い
  • CloudShell上でquemu動かしてNetBSD起動
  • 無事に Leaf Rogue を動かせた

LT10: リモートワーク主流の世の中だからこそ古の時代に思いをはせる with CloudShell

講師:watanabe.seigo (gb-swatanabe) さん

ターミナルでマインスイーパーを起動する話でした。

  • 古の時代
    • データセンタに行く(物理的に)
    • LED, 物理配線、物理スイッチ、物理作業
  • 暇つぶしはマインスイーパ
    • プリインストール、通信もない、ばれないので
  • terminal-mines
    • ascii only で make

LT11: AWS CloudShellでAWS CLI v1を実行する方法

講師:AWS 亀田さん

  • aws v2 をアンインストール
    • rm で消すだけ
  • v1 をインストールして、パスを通す
    • 再起動すると一部のファイルを CloudShell が書き戻してしまう
  • IAM のクレデンシャルはどこからとってるか分からない
    • aws configure に入ってない
      • Cloud9 は入っている、時限式で5分ごとに書き換えられる

LT12: (仮) CloudShellの細かすぎて伝わらないネタ集

講師:Hiroki Uchida (@nikuyoshi) さん

  • シェル環境にこだわりたい
    • oh-my-zsh, ph-my-fish などを維持したい
  • sh -c "$(curl -fsSL http://bit.ly/oh-my-cloudshell)"
    • Ansible の実行からプレイブックの実行まで自動で行いセットアップ

github.com

トリさんの締め

  • 誰もが叩くコマンドを叩いてみよう
    • name -r AL2 で動いてそう
    • env トークンを取るエンドポイントとオーサライズヘッダーがありそう
    • dmesg Fargate って文字があるような

所感

真面目な話から今後役に立ちそうな話、ojichat の狂気までとてもおもしろい内容でした。