※1 GKEは99.9%出てきません使う用事できたらその時にやります
※2 cloud identityにて組織化されてます組織なしでやり方が変わるのかはわかりません！
※3 深く語ろうとすると1項目で2-3個記事出来上がるんじゃないかって思うので雑にいきます
※4 ドキュメントに書いてあること以上の説明はほぼありません。

何これ

ノールックデフォルト構成でOS loginにてインスタンスに接続するまで
カスタムVPC(サブネット)作ってその上に乗せたインスタンスに公開鍵認証にて接続するまで

1

ちょっと触る/開発人数が少ないならこれで十分説。

VPC

雑に言うと、AWSでもGCPでもなんでも、利用者からするとお庭を貸してもらってそこにサーバ(インスタンス)なりなんなりを作る　ってノリなのですが、VPCはその貸してもらう庭の範囲を自分で明言して管理しやすくする、ってなもんです。
AWSの方はNW設計をちょっとでもやったことがあればピンと来やすいですが、GCPはスケールがデカいというかなんというか。

AWSは「まず庭を作りたい国選んで。んでその中に陣地(サブネット)好きなように置いて」
GCPは「全国もうお前の庭だから、好きなところで勝手にここ俺の陣地(サブネット)とか言ってろ」

で、タイミングとしては多分プロジェクトに請求先アカウント紐づいた時点で、defaultって名前の__陣地セット__が出来てます。
この陣地セットは全リージョン分いきなり出来てるので怯みますが、実際にサーバインスタンス作る時に置きたい陣地選べるので気にしないでいきましょう。

あと、ルーティングの説明はこの記事ではしません。これをしっかり設定する必要がある要件を認識できる人はこんな記事に用がないはず…

ファイアウォール

defaultをそのまま使う上では気にしなくて良いです。上り(AWSでいうところのインバウンド)は初っ端からほぼ全部あいてます。
下り設定(AWSでいうところのアウトバウンド)は特に何も設定しない場合、GCP側で必ずブロックするポート以外の通信は暗黙で許可状態になっています。
気になるんじゃボケ！！と言う方は22番ポート以外を無効にしましょう。設定を削除しなくてもファイアウォールルールの編集画面から無効にできます。
なお、22番ポート設定のIP見て「これ自分のIPだけで良くね？」と思った方は、「cloud shellやらブラウザ接続する場合はその限りではない」と一旦覚え、そのままの設定にしときましょう。

compute engine

メタデータ設定してOS loginを可能にする

雑に言うと、メタデータは単に「設定」です。ENV:developmentみたいなもんです。
OS loginは、IAMでSSH接続を管理できるって仕組みです。恐らく内部的にはgoogleの腹の中に各IAMとそれに紐づいたSSH鍵を持ってて、それを使って接続してる感じだろうと思います。
ここまでこの記事読むような方は恐らくPJオーナーだろうと思うので、特に権限設定しなくても初めから必要な権限持ってると思います。

OS loginを利用可能にするにはメタデータにenable-oslogin:TRUEを設定する必要があります。
インスタンスごとに設定も可能ですが、今回はPJ全体に適用します。
言うてもナビゲーションメニューのcompute engineからメタデータを選択して設定するだけです。

VMインスタンス

この記事ではSSH接続した段階で任務達成なので相応の構成で作ります。

名前は適当で良いです。tekitouとしましょうか。
リージョンはデフォルトのアイオワもしくはオレゴンにしておきます。多分現段階最安です。
マシン構成は汎用・N1・f1-microにします。ブートディスクは好みで選んで良いです。sshdが動いてればそれで良いので。
ディスクサイズと種類はそのままにしておきます。

他は全てデフォルトのまま、1番下からほんのちょっと上あたりにある 管理、セキュリティ、ディスク、ネットワーク、単一テナンシーの左側にあるやけに小さいプルダウンアイコンクリックして詳細出します。

管理タブの中にメタデータってあると思います。OS login使う場合でPJ全体にenable-oslogin:TRUEを適用したくない場合はここで設定します。PJ全体設定してある場合はスルー。
他の項目も全部今はスルーで。

セキュリティタブから、プロジェクト全体の SSH 認証鍵をブロックにチェック入れます。
enable-oslogin:TRUEの場合、メタデータに設定された認証鍵によるログインは全部自動的に無効になるらしいのですが、設定で明示できることはしといたほうが大抵後から楽です。

ネットワーキングタブから、ネットワークインターフェースがdefaultになってるのを確認して右側の鉛筆アイコン押します。
そうすると、サブネットワークんところにもdefault(cidr)ってなってるのが確認できるかと思います。
もしアイオワを選んでるなら、ナビメニューのVPCネットワークから確認できるdefault vpcのサブネット一覧のus-central1のcidrと一致してるのを確認できるはずです。
これは、「ぐーぐるさんの巨大なお庭の中の俺ののアイオワ陣地にtekitouを作る」ってなもんです。
オレゴンを選んでる場合も同様で、us-west1と一致してるはずです。
何も変更してないのでキャンセルを押します。

その後、作成を押します。

接続

VMインスタンスの一覧にtekitouが出てくると思うのでちょっと待ちます。
待ってると、内部IP/外部IPが振られ、接続のプルダウンが開けるようになるので、gloudコマンドを表示を選択し、出てくるモーダルの下の方にある「cloud shellでやる」みたいなの選択します。
あるいは、画面上部の右側にあるcloud shellアイコン叩いてあらかじめ起動しておき、コマンドコピペでもokです。
たまに、というか結構な頻度でcloud shellのプロビジョンが一向に終わらない時があるので、そういうときは容赦なくリロードしましょう。
無事起動したらコマンド入れてエンターすれば接続できるかと思います。
初回warning出ますが、それはいわゆる「…見かけねー顔だな」ってやつなので今は気にしないで良いです。

ブラウザでの接続は安定しないというか、何度ウィンドウ開いても接続が一向に始まらなかったりするのでつらいです。cloud shellのがまだマシです。なのでおすすめしません。

ファイアウォールの項で自IPだけにしなかったのはこの都合で、ブラウザ接続にせよclodu shellにせよ、これ内部的には

俺 -> ぐーぐる接続用インスタンス -> tekitou

の図式となっており、自IPだけを許可の状態にするとぐーぐる接続用インスタンスのIPを蹴っちゃうことになります。
ぐーぐる接続用インスタンスのIP範囲だけに絞りたい場合は

この辺見れば大丈夫。ただこれ急に変わることがあるので、ある日急に繋がらなくなったら確認しなおす必要はあります。

全てつつがなく終えたら

VM/メタデータは消しときましょう。microは普通に使うのきっついです。激遅です。

2

従来に近いやり方をGCPでやるって感じですね。認証鍵の管理を今後どうしていくか、とかはこの記事とは関係ない部分なので触れません。

VPC

VPCネットワークから、画面上部にあるVPCネットワーク作成を選択します。
名前や説明を適当に入れ、サブネット作成モードはカスタム。
自分の場合、今回作るVPC(サブネット)は普通に今後も使うのでasia-northeast1を選択します。
俺は大阪在住なんだ！2やろ！とかいう意見は黙殺します。
とりあえずノリだけつかんでおきたいならアイオワorオレゴンで良いかと。
名前はパッと見でどこのリージョンかわかるようにしとくと楽かなと思います。

IPアドレス範囲(cidr)はプライベートIPアドレスの範囲である必要があります。(RFC 1918に範囲載ってます)
AWSは範囲から外れても設定できるらしいんですが、GCPだとちょっとわかりません。でも範囲をぶっちぎりたいケースってあんまりない気がします。
範囲はちゃんと要件によって考えるべきではありますが今回はとりあえず馴染みありそうな192.168.0.0/24とかにしときましょうか。これで今の段階だと、自分の場合asia-northeast1で192.168.0.1-192.168.0.254まで利用可能な陣地を1個得たことになります。
もっと詳しく知りたい方はGCP公式と一緒にcidrについての資料を別途確認しましょう。
ただ、なんとなく、GCPというかgoogleは「なんで今だにサーバを1個構築するだけでそんなん覚えないといけない？俺らに任せとけよ」って思想な気がしています。今のところ。

限定公開Googleアクセスはオフにします。今回は普通にパブリックIP与えるので。
ここをオンにすると、インターネットに出ていない(パブリックIPを持たない)インスタンスでも0.0.0.0を利用してGoogleAPIと通信できるようになる、ってな感じらしいのですが、プライベートサブネットなら外界へ出るときの道は自分ならNATに絞りたいので今後もオンにすることはないかなあ感。
ここがオンでなおかつNATもある場合でルート指定しない場合どっちかが優先されるんだろうか。
オンにした段階でルート設定されたりするんかな？

フローログはオンにしておきます。今回記事で直接使いませんが、後々フローログはどのようなフォーマットで出力されるのかとか確認するために結局一度はオンにするので。試しに作るだけ作って全部後で捨てる予定の方はオフで良いかなと。

ダイナミックルーティングモードはデフォルトのままで良いです。ルート設定と同様、ここをグローバルにする必要がある要件であると作る段階で認識できる方はこの記事に用はない層だろうと思います。

DNSサーバポリシーもデフォルトのままで。

で、作成押します。

ファイアウォール

defaultと違い、自前でこしらえた生まれたてのVPCは上りは全部閉まってます。下りは前述したようにごく一部除いて最初から暗黙で全開放。一部例外はありますが、「上りの場合はルールが無ければ閉まってる」「下りは無ければあいてる」って覚えておきましょう。この辺は個人的にAWSのアウトバウンドデフォルトの「0.0.0.0/0 全て許可」って明示されてるほうが好きです。

名前や説明はお好みで。ただ名前はわかりやすいするものにするのがまあ大体良いですね。

ログはオンにしておきます。VPCフローログと同じ理由です。

ネットワークはさっき自分で作ったものを指定します。

優先度はデフォルトのままで。正直、相反するルールが多数あって優先度で管理する、とかドチャクソ混乱しそうに思えます…どうなんでしょうね。

トラフィックの方向は上りのまま。前述しましたが上りはインバウンド、「俺からぐーぐる」です。下りは逆。

一致アクションは「許可」で。いわゆるホワイトリスト方式。

ターゲットは「指定されたターゲットタグ」を選択します。恐らく実運用するときはこれが1番多いであろうからです。
ターゲットタグは適当にssh-testとか入れときます。

ソースフィルタはIP範囲で、範囲は今度こそ自IPだけを入れます。この際、AWSと違い、自IPをcidr形式で入れる必要はありません。っていうか入れようとすると多分怒られます。

2番目のソースフィルタはスルー

プロトコルとポートはその他チェックでtcp:22って入れます。tcpにチェックして22って入れても良いのですが、作ったあとの編集画面のUIが微妙に違い、編集のほうだとこのチェックボックスが出てこないので、無い方に慣れておきます。

編集画面のUIが違うのは本当ですが、その他プロトコルにtcpって入れたら「チェックボックスのほう使え」って怒られることが判明しました。おとなしくtcpにチェックいれてテキストボックスに22って入れます。

あとはそのまま作成。

compute engine

メタデータにSSH認証鍵設定

鍵セットの作成方法は割愛します。ぐぐればめっちゃくちゃ引っかかります。ed25519でぐぐりましょう。
鍵作り終わったら、enable-oslogin:TRUEの時でも開いたメタデータいって、今度はSSH認証鍵タブを選択します。
もしed25519で作成したのであれば、
ssh-ed25519 [[AAAA....]] [[ログインユーザ名]]
ってテキストボックスにぶちこんで保存押します。

これもosloginと一緒でインスタンス単位に設定できます。
ただ俺は今回の場合だとPJオーナーで管理者みたいなもんだし、全部に入れてもいいかなあーとかそんな感じで全体へ設定。

VMインスタンス

ほぼほぼ1と一緒なので相違点のみ。

リージョンはサブネット作ったリージョンと同じリージョンにします。

管理タブはスルー。

セキュリティタブから、プロジェクト全体の SSH 認証鍵をブロックにチェックが入ってないことを確認します。
ここでさっきメタデータに入力した認証鍵を入れると、このインスタンスのみに鍵が適用されます。

ネットワーキングタブから、
ネットワークタグにssh-testを入れておきます。これでこのインスタンスにさっき作ったファイアウォールルールが適用されます。
次に、ネットワークインターフェースの右側の鉛筆アイコン押します。
ネットワークをさっき作ったVPCに変えます。そうすると自動的にサブネットも切り替わるかと思います。
他は全部そのままにしておき、完了を押します。

その後作成押します。

接続

1と同様、ちょっと待ちます。
外部IPが振られたら、普段使いのターミナルで、作った公開鍵と対になる鍵指定で接続しましょう。
繋がるはずです。

全てつつがなく終えたら

同じく設定したものとVMは一旦消しときましょう。

男坂

とりあえず構築の「こ」の字の一画目あたりですが、「とりあえず使ってみよう」ならこの時点で既に使えるようになってるかと思います。
なおぐーぐるさんいわく、「本番環境で自動サブネット作成使うのはおすすめしないぞ」らしいんですけど、だったらdefaultVPCに全サブネット切るのやめーや！！！！！って言いたくなる。まあ、インスタンスとりあえず1個作ってみるのにまずサブネット作るところから始めないといけないのはまずいやねってことなんだろうけども。

次回はcloud natとLBかな。