许可“ artifactregistry.repositories.downloadartifacts”拒绝资源
尽管工件存储库正在成功创建,但即使在授予我在GCLOUD CLI上使用的会计中,运行Docker推动将图像推向Google文物注册表的失败。
命令用于推动图像:
docker push us-central1-docker.pkg.dev/project-id/repo-name:v2
错误消息:
The push refers to repository [us-central1-docker.pkg.dev/project-id/repo-name]
6f6f4a472f31: Preparing
bc096d7549c4: Preparing
5f70bf18a086: Preparing
20bed28d4def: Preparing
2a3255c6d9fb: Preparing
3f5d38b4936d: Waiting
7be8268e2fb0: Waiting
b889a93a79dd: Waiting
9d4550089a93: Waiting
a7934564e6b9: Waiting
1b7cceb6a07c: Waiting
b274e8788e0c: Waiting
78658088978a: Waiting
denied: Permission "artifactregistry.repositories.downloadArtifacts" denied on resource "projects/project-id/locations/us-central1/repositories/repo-name" (or it may not exist)
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(6)
我能够重新创建您的用例。当您尝试在
存储库上推动图像
,其中其特定主机名(与其存储库位置关联)尚未添加到凭证辅助辅助配置以进行身份验证时。您可以参考此设置Docker的身份验证也由 @ Dazwilkin在评论中以获取更多详细信息。在我的示例中,我试图在具有
us-east1
位置的存储库上推出图像,并且由于尚未将其添加到凭证辅助辅助配置中,因此遇到了相同的错误。我使用以下命令进行了身份验证(特别适用于us-east1,因为它是我的存储库的
位置
),该图像被成功推动:快速提示 :当您在控制台,然后单击
设置指令
。I was able to recreate your use case. This happens when you are trying to push an image on a
repository
in which its specific hostname (associated with it's repository location) is not yet added to the credential helper configuration for authentication. You may refer to this Setting up authentication for Docker as also provided by @DazWilkin in the comments for more details.In my example, I was trying to push an image on a repository that has a location of

us-east1
and got the same error since it is not yet added to the credential helper configuration.And after I ran the authentication using below command (specifically for us-east1 since it is the
location
of my repository), the image was successfully pushed:QUICK TIP: You may get your authentication command specific for your repository when you open your desired repository in the console, and then click on the

SETUP INSTRUCTIONS
.对我来说,这是ubuntu的配置文件位置的问题。下面的链接帮助我解决了问题
https://jhartman.pl/2022/03/23/how-to-fix-permission-artifactregistry-repositories-downloadartifacts-denied-当to-ubuntu-on-ubuntu-the-tofrom-google-artifact-repository/时
For me it was an issue with config file location for ubuntu. Below link helped me to resolve the issue
https://jhartman.pl/2022/03/23/how-to-fix-permission-artifactregistry-repositories-downloadartifacts-denied-on-resource-on-ubuntu-when-pulling-from-google-artifact-repository/
另一个问题也可能是GCP项目当前在您的GCLOUD配置中设置的项目并不是包含您要将图像推向的存储库的项目。例如,尝试推动到欧洲 - west1-docker.pkg.dev/project123/但是GCLOUD配置具有Project456集。要检查GCLOUD配置中的项目集,请运行以下命令。
为了将该项目的repo运行以下命令更新为一个项目。
Another issue might also be that the gcp project currently set in your gcloud config is not the one that contains the repo you are trying to push the image to. e.g trying to push to europe-west1-docker.pkg.dev/project123/<repo_name>/<app_name> but the gcloud config has project456 set. To check the project set in the gcloud config, run the following command.
In order to update the project to the one that has that repo run the following command.
正如 @saurabh-umathe指出的那样,解决方案是:
PS:感谢我的页面!
As pointed by @saurabh-umathe, the solution is:
PS: Thanks referring to my page!
以下 gcloud notalone
gcloud容器簇Get-Credentials&lt; cluster-name&gt; -gregion = us-east1-b
gcloud计算ssh&lt; node-pool eg:gke-my-cluster-default-efault-pool-2121ca21-rn93&gt; - Zone US-East1-B
Docker-Credential-GCR configure-docker -registries = us-east1-docker.pkg.dev.dev
,然后能够
docker plup &lt; image链接例如:us-east1-docker.pkg.dev/csci-5409-cloud-computing/container1/my-ymy-app>
Following GCloud Standalone Cred solved it for me
gcloud container clusters get-credentials <cluster-name> --region=us-east1-b
gcloud compute ssh <node-pool eg: gke-my-cluster-default-pool-2121ca21-rn93> --zone us-east1-b
docker-credential-gcr configure-docker --registries=us-east1-docker.pkg.dev
Then was able to
docker pull <image link eg: us-east1-docker.pkg.dev/csci-5409-cloud-computing/container1/my-app>
就我而言,问题是GCE实例与任何服务帐户没有关联。解决此问题:
该实例也没有外部IP,但是我认为这在这里没有相关。
In my case the issue was with the GCE instance not being associated with any service accounts. To fix it:
Also the instance had no external IP, but I don't think that's relevant here.