--- id: "18300" Google: https://support.cloud.google.com/portal/cases/details;name=metallicBillingAccounts%2F00C232-7C03B2-14F2EF%2Fcases%2F51640803 Slack: https://topgate.slack.com/archives/CDBNPLL2X/p1717463980487149 Zendesk: https://topgate-support.zendesk.com/agent/tickets/18300 --- # 18300 ## 2024-06-04 Incoming トップゲートサポートご担当者様 お世話になっております。 AKKODiSコンサルティング株式会社 坂上です。 【概要】 弊社にてVM(GCE)にOpsエージェントをインストールした際にエラーログが出力されるようになりました。 弊社にて一旦対応を実施しましたが、その対応で問題がないか判断するため、当該エラーについてご教示いただきたいです。 下記の【質問】の内容について、ご教示ください。 【状況の詳細】 Compute Engineにて、Debian10のVMにOpsエージェントをインストールしたところ、下記の"<エラーログ(1)>"が出力されるようになりました。 <エラーログ(1)> gce_workload_cert_refresh[26963]: 2024/06/03 17:09:12: Error getting config status, workload certificates may not be configured: HTTP 404 ワークロードの認証で発生したエラーだったため、下記の"<URL(1)>"を参考にして確認コマンドを実施しました。 <URL(1)> https://cloud.google.com/compute/docs/troubleshooting/troubleshooting-workload-to-workload-auth?hl=ja#spiffe-dir-not-exist 確認コマンドの結果は、下記の"<確認コマンドの結果>"の通りです。 <確認コマンドの結果> ``` # curl "http://metadata.google.internal/computeMetadata/v1/instance/gce-workload-certificates/config-status" -H "Metadata-Flavor: Google" Error 404 (Not Found)!!1

404. That’s an error.

The requested URL /computeMetadata/v1/instance/gce-workload-certificates/config-status was not found on this server. That’s all we know. # ``` "<URL(1)>"によれば、「ワークロード間認証をサポートしていないVMであることが原因」のようです。 また対策は「マネージド ワークロード ID を有効にすること」と書かれています。 しかし下記の"<URL(2)>"によれば、この「ワークロード間の認証」機能はpre-GA版のようであり、弊社では利用する必要はないと考えています。 <URL(2)> https://cloud.google.com/compute/docs/access/authenticate-workloads-over-mtls?hl=ja そのため、対策として下記のコマンドを実施したところ、"<エラーログ(1)>"は出力されなくなりました。 systemctl stop gce-workload-cert-refresh.timer systemctl disable gce-workload-cert-refresh.timer 【質問】 <質問(1)> "<エラーログ(1)>"の原因は「/var/run/secrets/workload-spiffe-credentialsディレクトリがないことによるワークロード間の認証の失敗」で正しいでしょうか? <質問(2)> 下記コマンドを実施する対応を取りましたが、pre-GA版である「ワークロード間の認証」機能を利用しない場合は、この対策でも問題ないでしょうか? systemctl stop gce-workload-cert-refresh.timer systemctl disable gce-workload-cert-refresh.timer 以上です。よろしくお願いします。 ## 2024-06-05 Sent AKKODiSコンサルティング株式会社 坂上 様 いつもお世話になっております、トップゲートサポートの高井です。 お問い合わせいただきありがとうございます。 お問い合わせいただいた内容につきまして、現在弊社にて内容を確認しております。 お待たせしており恐れ入りますが、ご案内まで少々お時間いただけますと幸いです。 引き続きよろしくお願いいたします。 ## 2024-06-06 Sent AKKODiSコンサルティング株式会社 坂上 様 いつもお世話になっております、トップゲートサポートの高井です。 > <質問(1)> > "<エラーログ(1)>"の原因は「/var/run/secrets/workload-spiffe-credentialsディレクトリがないことによるワークロード間の認証の失敗」で正しいでしょうか? お問い合わせいただいた内容について当方で検証しておりますが、こちらの原因について正確に確認できかねる部分がございました。 そのため、ご提供いただいた情報を元にGoogle での調査を依頼いたしましたので、恐れ入りますが進捗確認次第ご連絡させていただきます。 ご不便おかけし恐れ入りますが、ご案内まで少々お待ちくださいませ。どうぞよろしくお願いいたします。 ## 2024-06-10 Sent AKKODiSコンサルティング株式会社 坂上 様 いつもお世話になっております、トップゲートサポートの高井です。 ご案内にお時間いただいており恐れ入ります。 保留となっておりましたご質問について、下記にご案内いたします。 > <質問(1)> > "<エラーログ(1)>"の原因は「/var/run/secrets/workload-spiffe-credentialsディレクトリがないことによるワークロード間の認証の失敗」で正しいでしょうか? > > <質問(2)> > 下記コマンドを実施する対応を取りましたが、pre-GA版である「ワークロード間の認証」機能を利用しない場合は、この対策でも問題ないでしょうか? > `systemctl stop gce-workload-cert-refresh.timer` > `systemctl disable gce-workload-cert-refresh.timer` こちらにつきまして、認識に相違ございません。原因に関して詳細を説明いたします。 `gce-workload-cert-refresh.timer` systemd unitはメタデータサーバーの `workload-certificates-config-status` をチェックすることで、機能が有効か確認を試みます。有効でない場合、提示いただいたような404エラーが発生します。 こちらのsystemd unitはタイマーとなっており、10分毎に実行されるようになっております。 そのため、こちらのsystemd unitを無効化する対応をいただければ問題ございません。 ご質問いただいております内容への回答は以上となりますが、認識の相違ある場合や不明点などありましたらお知らせくださいませ。 引き続きどうぞよろしくお願いいたします。 ## 2024-06-11 Incoming トップゲートサポート 高井様 いつもお世話になっております。 AKKODiSコンサルティング株式会社 坂上です。 ご回答ありがとうございます。 > こちらにつきまして、認識に相違ございません。 認識に相違ない旨、承知しました。 またsystemd unitの仕様についても、とても参考になりました。 本件について追加の質問はございませんので、クローズでお願いします。 ご対応ありがとうございました。 以上です。よろしくお願いします。 ## 2024-06-12 Sent AKKODiSコンサルティング株式会社 坂上 様 お世話になっております。トップゲートサポートの高井です。 ご連絡ありがとうございます、本件クローズの旨承知いたしました。 これからも坂上 様が少しでもお困りなことや不安なこと等ございましたらいつでもお問い合わせ下さい。 ご満足いただけるよう、できる限りお手伝いさせて頂きます。 本件はこちらのメールをもちましてご案内終了とさせていただきます。 今後ともどうぞよろしくお願いいたします。