markdownlint fix 2023

Author: ma91n

source/_posts/2023/20230105a_Python_Web_APIをAWS_Lambdaにデプロイ.md

@@ -14,7 +14,6 @@ lede: "この記事はフューチャー Advent Calendar 2022の14日目の記
 ---
 この記事は[フューチャー Advent Calendar 2022](https://qiita.com/advent-calendar/2022/future)の14日目の記事です。
 
-
 # はじめに
 
 こんにちは。TIG DXユニットの村上です。
@@ -27,7 +26,6 @@ PythonでWeb APIを構築する方法は[OpenAPI GeneratorでPython Web API構
 
 <img src="/images/20230105a/image.png" alt="PythonアプリをDockerコンテナイメージビルド→ECR→Lambdaにデプロイする" width="778" height="495" loading="lazy">
 
-
 # Lambda起動用のモジュール
 
 Lambdaでは起点となる関数とAPI Responseを返すreturn命令が必要になります。
@@ -54,6 +52,7 @@ def lambda_handler(event, context):
 # デプロイする方法
 
 Lambdaにソースコードをデプロイする方法は2種類あります。
+
 1. ソースコードとその依存ライブラリをZIPにアーカイブしてアップロードする
 2. ECRのコンテナイメージをアップロードする
 
@@ -124,7 +123,7 @@ $ docker build \
 ビルドができたらECRにプッシュします。
 
 ```bash
-$ docker push <AWSアカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com/<ECRリポジトリ名>:latest
+docker push <AWSアカウントID>.dkr.ecr.ap-northeast-1.amazonaws.com/<ECRリポジトリ名>:latest
 ```
 
 プッシュが完了したらECRからLambdaにアップロードします。

source/_posts/2023/20230113a_GKEでIdentity-Aware_Proxyを利用したWebアプリケーション認証.md

@@ -13,22 +13,22 @@ author: 渡邉光
 lede: "GKE を利用したWebアプリケーションのGoogleアカウント認証について記事を書きます。公式ドキュメントを引用します。IAP を使用すると、HTTPS によってアクセスされるアプリケーションの一元的な承認レイヤを確立できるため、ネットワーク レベルのファイアウォールに頼らずに、アプリケーション レベルのアクセス制御モデルを使用できます。"
 ---
 # 初めに
+
 明けましておめでとうございます！Future筋肉エンジニアの渡邉です。年も明けたことなので切り替えて減量に入りました。三月末までを目安に体を絞ろうと思っています。
 
 私は現在Google Cloudを利用しているプロジェクトに所属しており、Google Cloudのスキルアップにいそしんでいます。今回はGKE (Google Kubernetes Engine)でCloud IAP (Identity-Aware Proxy)を利用したWebアプリケーションのGoogleアカウント認証について記事を書こうと思います。
 
 # Identity-Aware Proxyとは
+
 以下、[公式ドキュメント](https://cloud.google.com/iap/docs/concepts-overview?hl=ja)引用
 > IAP を使用すると、HTTPS によってアクセスされるアプリケーションの一元的な承認レイヤを確立できるため、ネットワーク レベルのファイアウォールに頼らずに、アプリケーション レベルのアクセス制御モデルを使用できます。
 
 簡単に言うとGoogleアカウントとCloud IAMの仕組みを用いてWebアプリケーションの認証をすることができます。
 
-
 ## 認証・承認フロー
 
 <img src="/images/20230113a/authenticate-flow.drawio.png" alt="authenticate-flow.drawio.png" width="487" height="564" loading="lazy">
 
-
 [公式ドキュメント](https://cloud.google.com/iap/docs/concepts-overview?hl=ja)はこちら
 
 - Google Cloudリソースへのリクエスト(Cloud Load Balancing)します。
@@ -39,15 +39,15 @@ lede: "GKE を利用したWebアプリケーションのGoogleアカウント認
 - 認証サーバはこのIDからユーザのIAMロールをチェックし、ユーザがリソースにアクセスできる権限(**IAP で保護されたウェブアプリ ユーザー**)を持っているかをチェックします
 - 権限を持っていれば、アクセスOKになり、なければNGになります。
 
-
-
 # 全体アーキテクチャ図
+
 以下が全体アーキテクチャ図になります。
 GKE/NetworkなどのGoogle Cloudのリソース構築に関しては慣れ親しんでいるTerraformを利用して作成しました。OAuth同意画面に関しては外部公開する場合は、APIから作成することはできない ([公式ドキュメント記載](https://cloud.google.com/iap/docs/programmatic-oauth-clients?hl=ja]))ので、コンソール画面から設定しました。
 
 <img src="/images/20230113a/architecture.drawio.png" alt="architecture.drawio.png" width="1151" height="429" loading="lazy">
 
 ## Bastion初期設定
+
 Public Subnetに作成したGCEインスタンスからGKEのコントロールプレーンに対してkubectlコマンドを実行したいので、
 kubectlコマンドや、google-cloud-sdk-gke-gcloud-auth-pluginなどをインストールします。
 以下、Bashスクリプトです。
@@ -89,11 +89,13 @@ kubectl get node
 ```
 
 ## manifestファイル
+
 また、manifestファイルは以下を用意してkubectlコマンドを実行しk8sリソースをGKEに対して作成しました。
 
 ここまでの設定で事前準備は完了です。
 
 ### Deployment
+
 NginxのPodを用意するため、Deploymentのmanifestを作成しました。
 
 ```yaml deployment.yaml
@@ -119,6 +121,7 @@ spec:
 ```
 
 ### Service
+
 IngressにはNodePortが必要になるので、Serviceのmanifestを作成しました。
 
 ```yaml service.yaml
@@ -137,6 +140,7 @@ spec:
 ```
 
 ### ManagedCertificate
+
 クライアントとIngressで構築するHTTP(S)ロードバランサ間をHTTPSでアクセスするようにしたいので、Googleマネージド証明書のmanifestを作成しました。
 domainsには、terraformで用意したHTTP(S)ロードバランサに設定したい外部IPアドレスにフリーなワイルドカードDNSサービスの[nip.io](https://nip.io/)を利用したものを設定します。
 
@@ -151,6 +155,7 @@ spec:
 ```
 
 ### Ingress
+
 インターネット上にNginxを公開するためにIngressを構築するmanifestを作成しました。
 
 ```yaml ingress.yaml
@@ -180,15 +185,14 @@ spec:
               number: 80
 ```
 
-
-
 # Cloud IAPなしでのアクセス確認
+
 まず、Cloud IAPなしでのアクセス確認を行います。
 Load Balancerに設定したドメインに対してアクセスを行うと、特に認証画面を経由することもなくアクセスすることができます。
 <img src="/images/20230113a/1-IAPなしでのアクセス確認.png" alt="1-IAPなしでのアクセス確認.png" width="956" height="525" loading="lazy">
 
-
 # Cloud IAPの設定を追加
+
 上記の状態ではだれでもアクセスすることが可能なため、セキュアな状態ではありません。
 ここでCloud IAPの設定を追加してみましょう。
 
@@ -214,6 +218,7 @@ OAuth同意画面はUser Typeを「外部」で作成します。
 <img src="/images/20230113a/2-OAuth同意画面④.png" alt="2-OAuth同意画面④.png" width="1200" height="844" loading="lazy">
 
 ## OAuth認証情報の作成
+
 APIとサービスタブの「認証情報」をクリックします。
 認証情報の作成プルダウンリストからOAuthクライアントIDをクリックします。
 
@@ -230,13 +235,15 @@ APIとサービスタブの「認証情報」をクリックします。
 <img src="/images/20230113a/3-OAuth認証情報③.png" alt="3-OAuth認証情報③.png" width="512" height="448" loading="lazy">
 
 作成したOAuthクライアントを再度クリックし、承認済みリダイレクトURIをダウンロードしたOAuthクライアントID(CLIENT_ID)に修正して保存します。
+
 ```
 https://iap.googleapis.com/v1/oauth/clientIds/CLIENT_ID:handleRedirect
 ```
 
 <img src="/images/20230113a/3-OAuth認証情報④.png" alt="3-OAuth認証情報④.png" width="1200" height="795" loading="lazy">
 
 ## IAPアクセス権の設定
+
 Google Cloud ConsoleのIdentity-Aware Proxyにアクセスします。
 アクセス権を付与するリソースの横にあるチェックボックスをオンにします。
 
@@ -255,8 +262,8 @@ IAPアクセスを許可したいGoogleアカウント（メールアドレス
 
 ここまででOAuthの設定は完了です。
 
-
 ## Kubernetes Secretの作成
+
 GKEでCloud IAPを適用するためには、Kubernetes Secretを作成してBackendConfigに適用する必要があります。
 先ほど作成してダウンロードしたOAuth認証情報のClient IDとClient Secretを指定してKubernetes Secretを作成します。
 
@@ -266,6 +273,7 @@ kubectl create secret generic oauth-secret --from-literal=client_id=xxxxxxxxxxxx
 ```
 
 Kubernetes Secretが作成されていることを確認します。
+
 ```bash
 xxxxxxxxxxxxx@tky-bastion:~$ kubectl describe secret oauth-secret
 Name:         oauth-secret
@@ -282,6 +290,7 @@ client_id:      73 bytes
 ```
 
 ## BackendConfigの作成
+
 Kubernetes Secretで作成したSecretをBackendConfigに設定することでCloud IAPを適用することができます。
 以下のmanifestファイルを用意します。
 
@@ -299,11 +308,13 @@ spec:
 ```
 
 kubectlコマンドでBackendConfigを作成します。
+
 ```bash
 kubectl apply -f backendconfig.yaml
 ```
 
 BackendConfigが作成されていることを確認します。
+
 ```bash
 xxxxxxxxxxxxx@tky-bastion:~/manifest$ kubectl get backendconfig
 NAME         AGE
@@ -336,31 +347,29 @@ kubectl apply -f service.yaml
 
 以上で、Cloud IAPの設定は完了です。
 
-
 # Cloud IAPありでのアクセス確認
+
 Cloud IAPの設定が完了したので、画面にアクセスしてCloud IAPが適用されているかを確認します。
 
 ## Cloud IAP認証対象外アカウントでのアクセス確認
+
 Load Balancerに設定したドメインに対してアクセスを行うと、Cloud IAPによるGoogleアカウントログイン画面にリダイレクトされます。
 
 <img src="/images/20230113a/5-IAPアクセスなし①.png" alt="5-IAPアクセスなし①.png" width="469" height="557" loading="lazy">
 
 本GoogleアカウントはCloud IAPのアクセスできる権限(**IAP で保護されたウェブアプリ ユーザー**)を持っていないため、画面にアクセスすることはできません。
 <img src="/images/20230113a/5-IAPアクセスなし②.png" alt="5-IAPアクセスなし②.png" width="426" height="455" loading="lazy">
 
-
-
 ## Cloud IAP認証対象アカウントでのアクセス確認
+
 Load Balancerに設定したドメインに対してアクセスを行うと、Cloud IAPによるGoogleアカウントログイン画面にリダイレクトされます。
 
 <img src="/images/20230113a/6-IAPアクセスあり①.png" alt="6-IAPアクセスあり①.png" width="529" height="565" loading="lazy">
 
 本GoogleアカウントはCloud IAPのアクセスできる権限(**IAP で保護されたウェブアプリ ユーザー**)を持っているため、画面にアクセスすることができました。
 <img src="/images/20230113a/6-IAPアクセスあり②.png" alt="6-IAPアクセスあり②.png" width="908" height="299" loading="lazy">
 
-
-
 # 最後に
+
 今回はGKE (Google Kubernetes Engine)でCloud IAP (Identity-Aware Proxy)を利用したGoogleアカウント認証について記事を書きました。
 Google Cloudを利用していて、特定のGoogleアカウントにのみアクセスを許可したいケースはあるかと思いますので、その時にでも参考にしていただければ幸いです。
-

source/_posts/2023/20230119a_VPC_Service_ControlでGoogle_Cloud環境をガッチリ守る.md

@@ -35,7 +35,6 @@ VPC Service Controlsを利用することによって、Google Cloudのリソー
 
 <img src="/images/20230119a/a864e1b2-7cd3-c69c-bf63-fe2b21622b6d.png" alt="" width="1200" height="640" loading="lazy">
 
-
 こちらの画像のように、境界（Service Perimeter）内に存在するBigQueryは認証されたVPC、VM（GCE）からのみアクセス可能となり、認証されていないリソースからは境界内へのアクセス・境界外へのアクセス共に制限されることになります。
 
 現在、VPC Service Controlsがサポートしているリソースの一覧はこちらになります。
@@ -51,7 +50,6 @@ VPC Service Controlsはそれに加えて、境界全体への上り（Ingress
 
 どちらが良い・悪いというのは無く、併用することでより強固なセキュリティを築くことが可能となります。
 
-
 ## BigQueryを使って挙動を確認
 
 ### Organizationの設定が必要
@@ -91,7 +89,6 @@ ID制御を行ってみます。
 
 <img src="/images/20230119a/755d759c-cde1-42d1-c0c4-e62dc1425a89.png" alt="" width="930" height="348" loading="lazy">
 
-
 #### アクセスレベルを作成する
 
 [アクセスレベル](https://cloud.google.com/access-context-manager/docs/overview#access-levels)ではリソースへのアクセスを許可する条件を定義します。
@@ -119,7 +116,6 @@ resource "google_access_context_manager_access_level" "id" {
 
 ```
 
-
 #### サービス境界を作成する
 
 VPC Service Controlsの主役です。指定したサービスのリソースに対して外部アクセスから保護するための境界を作ります。
@@ -267,7 +263,6 @@ resource "google_access_context_manager_access_level" "id_and_ip" {
 
 <img src="/images/20230119a/9de770bd-ea00-9238-2464-906a4bc2561a.png" alt="" width="795" height="320" loading="lazy">
 
-
 次に指定されたIPアドレスのVMに認証済みのアカウントで`gcloud auth login`してから`bq`コマンドを打ってみます。
 
 ```bash
@@ -324,7 +319,6 @@ bq query --use_legacy_sql=false --project_id <YOUR_PROJECT_ID>  'select worker_i
 
 <img src="/images/20230119a/34000be3-c373-0fe1-47b6-fdae7b41ec73.png" alt="" width="1078" height="374" loading="lazy">
 
-
 ではこの時、どのようにIngree/Egressを設定すればよいのでしょうか？
 正解は以下のようになります。
 

source/_posts/2023/20230120a_MailSlurperを使って6桁のコードの送信コードのテストをする.md

@@ -86,7 +86,7 @@ services:
 あとは起動するだけです。 http://localhost:8080 にアクセスして管理画面にアクセスできることを確認しましょう。
 
 ```bash
-$ docker compose up
+docker compose up
 ```
 
 <img src="/images/20230120a/スクリーンショット_2023-01-16_1.41.30.png" alt="スクリーンショット_2023-01-16_1.41.30.png" width="1200" height="684" loading="lazy">
@@ -307,5 +307,3 @@ func TestMain(m *testing.M) {
 これで実SMTPサーバーを使ったコードを書いて、それをMailSlurperを使ってテストする方法を学びました。REST APIのおかげで、ヘルパーさえ用意してしまえば、テストを書くのは簡単です。
 
 これだけ使いやすいとなると、非同期通信系は全部SMTPに寄せたくなってくる気もします。まあ本番環境の安定稼働を考えると実際にやることはないですが、MailSlurperは送信結果を見るのもできて、開発体験はかなり良いです。
-
-