如何确保GCP Start-Script使用正确的服务帐户？
我正在GCP的Compute Engine中创建一个使用服务帐户的VM，该计算帐户具有从特定的云存储存储桶中读取的许可，该量库包含一些可能包含敏感信息的常见配置，例如TLS证书。但是，当执行我的启动脚本时，由于使用Google Compente Engine默认服务帐户而不是我为使用的VM提供的服务帐户，因此被拒绝访问存储桶的权限。有人可以帮助我弄清楚如何确保启动脚本使用正确的服务帐户？
====================================
不会提供所有木偶代码。实例启动时调用的实际启动脚本是sudo puppet应用-verbose/opt/puppet/manifests/opensearch.pp＆gt＆gt;/var/log/puppetlabs/puppetlabs/puppet/startup/startup.log 2＆gt;。请注意，我已经确认Puppet对服务帐户没有做任何特别的事情。但是，Puppet始终使用默认服务帐户，并且无法下载证书。如果我进入实例并手工运行相同的命令，则每次都可以工作。
exec { 'download_ssl_certs':
command => "/snap/bin/gsutil cp -r gs://${opensearch::secrets_bucket}/${opensearch::cluster}/* ${opensearch::opensearch_path}/config/",
notify => Exec['ssl_certs_chown']
}
exec { 'ssl_certs_chown':
command => "/bin/chown -R ${opensearch::service_user}:${opensearch::service_group} ${opensearch::opensearch_path}/config",
onlyif => "/bin/ls -lhR ${opensearch::opensearch_path}/config | /bin/grep -i root | grep -v ${opensearch::service_user}",
refreshonly => true,
notify => Service['opensearch'],
}
I am creating a VM in GCP's Compute Engine with a service account that has permissions to read from a particular Cloud Storage bucket that contains some common configuration that may contain sensitive information, such as TLS certs. However when my startup script is executed, it is denied permission to access the bucket because it is using the Google Compute Engine default service account, not the service account I provisioned my VM to use. Can someone please help me figure out how to ensure that the startup script uses the right service account?
============= EDIT =============
Not sure how helpful this will be, but here is the puppet code that is failing, I can't/won't provide all of the puppet code. The actual startup script that is invoked when the instance starts is sudo puppet apply --verbose /opt/puppet/manifests/opensearch.pp >/var/log/puppetlabs/puppet/startup.log 2>&1. Note that I've already confirmed that puppet is not doing anything special with the service accounts. However puppet always uses the default service account, and fails to download the certs. If I SSH into the instance and run the same command by hand it works every time.
exec { 'download_ssl_certs':
command => "/snap/bin/gsutil cp -r gs://${opensearch::secrets_bucket}/${opensearch::cluster}/* ${opensearch::opensearch_path}/config/",
notify => Exec['ssl_certs_chown']
}
exec { 'ssl_certs_chown':
command => "/bin/chown -R ${opensearch::service_user}:${opensearch::service_group} ${opensearch::opensearch_path}/config",
onlyif => "/bin/ls -lhR ${opensearch::opensearch_path}/config | /bin/grep -i root | grep -v ${opensearch::service_user}",
refreshonly => true,
notify => Service['opensearch'],
}
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
示例：
创建和启用实例的服务帐户< /a>
由于服务帐户是元数据的一部分，因此您可以使用启动脚本访问元数据。
从Linux启动脚本访问元数据
Example:
Creating and enabling service accounts for instances
As the service account are part of metadata, you can access to metadata using startup scripts.
Accessing metadata from a Linux startup script