Google Cloud のアカウントがブロックされた経験を記録します。

Google Cloud 封禁の経験です。Dockerイメージを使用する際、認証ファイルが公開され、プロジェクトが停止されました。認証ファイルの管理方法とプロジェクトディレクトリに秘密鍵を置くリスクに注意が必要です。¶

普段、プロジェクトをデプロイする際にはDockerイメージにパッケージ化することが好きです。その利点は多くの人が理解しているでしょう。全体のデリバリープロセスは「ローカル開発 - イメージのパッケージ化 - Docker Registerへの公開 - サーバーでのイメージの取得 - 新しいイメージで古いコンテナを置き換える」となります。そのため、開発と運用の接点である「Docker Register」は非常に重要です。私が選んだのはGoogle CloudのGoogle Container Register、つまりgcr.ioです。

GCRにはさまざまな認証方法がありますが、私はローカル開発時にjson_keyを使用して認証する方法が好きです。ローカルでログインする必要はなく、専用の認証用jsonファイルを生成するだけで、プッシュするたびに認証が行われます。

しかし、このようなファイルの使用方法が好きだからこそ、自分自身にトラブルを引き起こしました。通常、私はGradleプラグインを使用してイメージのビルドとプッシュを行いますので、授権ファイルをプロジェクトのルートディレクトリに直接配置し、プラグインが相対パスでアクセスできるようにしました。

docker {
    ...
    registryCredentials {
        url = 'https://gcr.io'
        username = '_json_key'
        password = file(project.rootDir.path + '/gcr_keyfile.json').text
    }
    ...
}

学校のカリキュラムデザインを作成する必要があり、チームはGitHubを使用してコードの共同作業を行っています。便宜のために、プロジェクトをオープンソース化しましたが、json_keyを.gitignoreに追加するのを忘れてしまいました。その結果、json_keyはGitHubに簡単に公開されてしまいましたが、当時は全く気にしていませんでした。

1時間後に、Googleから何通かのメールが届きました。Google Cloudのプロジェクトが停止され、申し立てが必要だと通知されました。私は本当に理解できませんでした。このGoogle Cloudプロジェクトはイメージの保存にしか使用していません。どのような利用規約に違反したのでしょうか。最後に、Googleのメールを詳しく読んで初めて「まずい、json_keyが公開されていた」と気づきました。

Githubで急いでプロジェクトを削除し、ローカルでgitを再設定し、コードを再アップロードし、Googleに申し立てる。

Google Cloud 封禁の経験、Dockerイメージを使用する際に、認証ファイルが公開され、プロジェクトが停止されました。認証ファイルの管理方法とプロジェクトディレクトリに秘密鍵を配置するリスクに注意する必要があります。¶

Google Cloudは本当にすごいと感じます。クローラーを使用して、ユーザーの不適切な行動をすばやく検出し、ユーザーのプロジェクトを停止し、通知することで、ユーザーのデータの安全性を大幅に確保しています。

また、認証ファイルの管理に関しては、sshキーを .ssh ディレクトリに保存するように、すべての認証ファイルを固定の場所に保存し、グローバル変数を設定して、開発ツールがこの変数を介して認証ファイルに直接アクセスできるようにする必要があります。プロジェクトディレクトリに秘密鍵を置くことを完全に防止するために。