GCPのサービスアカウントの鍵を作って持ち出す必要がなくなった

Dec 21, 2019

背景

去年触っていた時は

Key Management Serviceについて勘違いしていたこと - あーありがち(2018-10-21)

こんな感じで、

GCPの中にコードを送り込むことを自動化する際にサービスアカウントを使うので、そのアカウントの鍵が必要
pkgcloud が keyFilename がないと激おこ

という理由で鍵をどう管理するかを考えていたのだけど、事情が変わって鍵の管理を全部不要にできたので、これをまとめておく。

まとめ

pkgcloud が 2019-04 時点で依存 npm を gcloud から @google-cloud に乗り換えたおかげで client library の挙動が正しくなった
- 動作時のサービスアカウントの default credentials と permissions を取得できる
Cloud Source Repositories & Cloud Build を使うことで Google Cloud の外から中へ入れる必要がなくなった

結果、サービスアカウントの鍵を Google Cloud 外に持ち出す必要はなくなった。

なくせたこと

これまでサービスアカウントの鍵を外に持ち出しつつリポジトリの中に鍵を納めないようにするため、

あちこちの環境変数に鍵の中身をぶちまける
必要に応じてこの環境変数の中身を鍵ファイルとして書き出し、その鍵ファイルのありかをコードに教える
- 例えば deploy 時、例えば実行時

という作業とコードの準備をしていたのだが、これらが一切不要になった。めでたい。

ではこれを可能にしたサービスを紹介する。

Cloud Source Repositories

Cloud Source Repositories | Google Cloud

Cloud Source Repositories は GitHub と Bitbucket に対して同期する機能を持っている
同期の際の認証は OAuth

この時点で Google Cloud の外から中へ持ち込むという課題はクリアしている。外から中へ持ち込むのではなく中から外へ取得しにいく形になる。

なお、次の Cloud Build の関係で、リポジトリはプロジェクト単位で作ることになる。Google Cloud は staging 環境用にもう一つプロジェクトを作ることを推奨しているので、production 用と staging 用のプロジェクト別にリポジトリを持つ形になる。

※ 2020 のいつ頃からか、Cloud Build の方で直接 Cloud Build GitHub アプリを使って GitHub に接続できるようになったので、ミラーが目的でないならそちらを利用する方がよいと思います。ビルドステータスを GitHub に返すことができるので。

Cloud Build

Cloud Build - 継続的インテグレーションのためのビルドの自動化 | Cloud Build | Google Cloud

設定は cloudbuild.yaml か Dockerfile で行う
各ステップ用に Docker コンテナが用意してあってそれらに YAML ファイルから指示を出す

これだけ読むと最近よく見るクソ面倒くさい CI/CD のように見えるが、少なくとも deploy に限ってはかなり簡単。理由は以下の通り。

Cloud Build が動き始めている段階で「目的のプロジェクトに属している状態で、かつその Project ID は環境変数として持っている
gcloud コマンドのインストールは不要（それ用のコンテナがある）
サービスアカウントの activation も不要（そもそもコンテナが Cloud Build 用のアカウントで動いている）
build の動く条件は cloudbuild.yaml 内ではなく trigger の方に指定する。cloudbuild.yaml 内に面倒な分岐は書く必要がない
- 1 の関係で deploy 先のプロジェクトは分かっているのでこれの切り替えも不要

少なくとも Google Cloud 外の CI から deploy するのに比べるとマジで何倍も楽。マジ。

Cloud Build もうちょっと早く出会いたかったぜ…。

参考

超今さら初めてのgisty

Dec 21, 2010

gisty を知ったのはもう記憶にもないくらい昔だし、直接勧められたのは

Twitter / ゆーけー/赤松祐希: @wtnabe gistにプロダクトコードとテストコ …

なんと3月なので9ヶ月前という体たらくでございますが、ようやく使ってみました < gisty

swdyh/gisty - GitHub

必要な準備

gisty gem
GISTY_DIR
git の config
使っている Ruby が参照できる OpenSSL 証明書

gisty を使うには clone する場所を環境変数で指定しておく。post するだけでも同時に clone するので GISTY_DIR の指定は必須である。

また、git の config は最終的にこんな形になればよい。

[github]
       user  = USERNAME
       token = XXXXXXXXXXXXXXXXXXXXXXX

いずれにしてもエラーメッセージを見ればどうすればよいかは分かるので簡単。

実は、4 でハマった。

Ruby の参照できる OpenSSL 証明書

なんかこれ前にもハマった気がするんだけど、今回は Mac OSX でどうやって解決したか。

gistyをMacから使う - Dive into the Tech World!

を見ると

$ ruby -ropenssl -e 'p OpenSSL::X509::DEFAULT_CERT_FILE'

で、どのファイルを見に行っているか分かる。見るとそこには何もファイルがない。

FreeBSD のとき（Ruby の SSL の証明書検証の失敗でハマっていた - あーありがち(2010-01-14)）には ca_root 関係の ports があったけど、MacPorts にはないっぽい。それっぽいのは

$ port search cert
curl-ca-bundle @7.21.2 (net)
    CA certificate bundle for curl

なので、これを入れて

/opt/local/etc/openssl/cert.pem@ ->
      /opt/local/share/curl/curl-ca-bundle.crt

の link を張って対処。

使い方

$ gisty help

で確認できる。（gisty –help ではない。）

gisty post *

としてできあがったのがコレ。

gist: 748375 - fabrication with faker and forgery- GitHub

ふー。長かった。

gisty syncに注意

gisty sync は自分の作った gist 全部を local に clone しようとする。その際、

1回1回鍵の passphrase を聞かれる。

自分は普段 ssh-agent とか使わないのでものすごく面倒になって途中でやめてしまった。

sync の際には ssh-agent や keychain を活用すべし。

COSINA が Fマウントの Zeiss を売ってたのか

Dec 21, 2006

ZF,ZS-top (cosina.co.jp)
コシナ、ニコンFマウントの「カールツァイスディスタゴンT*」 (デジカメWATCH)

※ なぜか Amazon には ZM マウントしか出てこないので写真が使えないぞ。

不覚にも全然認識してなかった。こんないいものが出ているとは。ちゃんと絞り連動用の爪までついてる！スバラシイ。（いや爪が必要なカメラ持ってないけど）

一眼なら（というかコンパクトでないなら）レンズはマニュアルで十分だと思っている人間なのでこれはとても魅力的。やっぱ狙うなら 35mm か。うーん、さすがにいいお値段しますなぁ。

ロイターのフィードが見にくくなった

Dec 21, 2006

Feed

最近広告が入るようになったんだけど、これが IBM の真四角のやつ。これはさすがにやめてほしい。こんなやつを入れられたらせっかくの一覧性が台無し。

classを名前空間の分離のためだけに使う

Dec 21, 2005

休んでるんだけどこんな実験。

何をしているのかというと、例えば PukiWiki みたいにグローバルな関数と global 宣言しまくりなコードをどうにかいじりやすくするためにとりあえず class で分けて、class::func() で呼ぶようにして、必要なときだけ extends して関数を override したら少しは扱いやすくなるかなーということの確認。分かったことは、

Perl の package とは違うので変数は使えない
グローバルスコープだろうが class内だろうが、同じ関数を二重に定義することはできない
extends して override することは通常通り可能

ほんとにただ :: を使って「関数の名前空間を分ける」だけに利用することは可能だってことですな。問題は global 宣言しまくりの変数の方か。

<?php
/**
 * クラスを名前空間の分離だけに利用するテスト
 */

print "<pre>\n";

class Hoge {
  function func() {
    echo "function name divided func()\n";
  }
}
function globalfunc() {
  echo "function global scope globalfunc()\n";
}
Hoge::func();
globalfunc();

class Fuga extends Hoge {
  function func() {
    echo "Fuga::func()\n";
  }
}
Fuga::func();
Hoge::func();

/*
// parse error
class First {
  class Second {
    function func() {
      echo "Double class is available ?\n";
    }
  }
}

First::Second::func();
*/

/*
// Fatal Error: Cannot redeclare class Hoge
class Hoge {
  function func() {
    echo "Hoge::func()\n";
  }
}
*/

print "</pre>\n";
?>

身体が動かねぇ

Dec 21, 2005

日々

風邪と雪かきのダブルパンチで体力的に限界。

Doxygen を PHP で試す

Dec 21, 2004

結論から言うとイマイチ。

PHP を使ってる人は phpdoc の方で満足してて Doxygen 方面に声が届いていないのかもしれない。個人的には PHP も JavaScript も全部 Doxygen の Javadoc スタイルでカバーできれば言うことなしだと思っていたんだけど、そんなに甘くないようだ。

まず根本的な問題として PHP に対応していると言いながら、Doxygen は「Javadoc スタイルのコメントが PHP の中にも書ける」程度にしか認識していない。設定ファイルの中に PHP に関する設定って出てこないし。やっぱ C/C++/Java を前提に作られている感じがすごくする。細かいところではファイルのインクルードを出力してくれないとかあるんだけど、基本的には

記述量少なめのスクリプト言語向きではない

感じがする。1.2.5 → 1.3.9 で HTML と PHP の混在にはずいぶん強くなったとは言え、まだまだ PHP の特徴をつかみきれてない。当面は phpdoc + jsdoc で行くのが現実的だと思う。Doxygen の latex 出力 → PDF 変換は結構ほしい機能なんだけどなぁ。

TWAIN SANE InterfaceでOS X非対応スキャナーを利用

Dec 21, 2003

from スラド

OS X の対応スキャナの数を増やす試みですな。

OS X は実は Classic OS を使ってなかった（MacOS 的には）門外漢の方が簡単にメリットを享受できるんだけど、デバイス周りもレガシーものはなかなか扱いが難しい。Mac って、OS はともかく本体は安くはないし、そのうえ周辺機器まで総取っ替えなんて、普通はできまへん。

こういう部分こそ Apple はもっと頑張ってほしいですな。アプリレベルで頑張ってデベロッパを窮地に追いやっちゃうようなことしてる場合じゃないんじゃないか。

（本当はあまり古い機械を壊れてないからって使い続けてる方がどうかなとも思うんだけど、普通、PC 以外の機械って壊れない限りは使い続けますわな。ベンダー側とユーザー側の意識がこれほど遠い業界って他にあるんだろうか。）

About

例によって個人のなんちゃらです