Skip to content

Docs: Providing clarity on registry and S3 communication

Adam Mulvany requested to merge docs-providing-clarity-on-registry-s3-communication into master

What does this MR do?

We are receiving requests from customers asking us to provide clarity around the original statement.

Two of these requests are:

The docs read: "Enabling a storage driver other than filesystem would mean that your Docker client needs to be able to access the storage backend directly." - am I correct in saying that by using S3, this is handled for me, or do I have to distribute access and secret key pairs to my users to configure their docker clients with?

and

This note in the docs is ominous: Note: Enabling a storage driver other than filesystem would mean that your Docker client needs to be able to access the storage backend directly. In that case, you must use an address that resolves and is accessible outside GitLab server.

That makes it sound like if I migrate to GCS for container registry storage, that my docker systems have go directly to GCS to download container images, not through the Gitlab registry server. Can you clarify that for me? My assumption is that nothing should change with respect to how my systems download container images from the Gitlab registry and that the only thing that changes is how Gitlab is storing them.

This update is to provide clarity to the above for our customers and users.

Screenshots

Does this MR meet the acceptance criteria?

Conformity

Availability and Testing

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

  • Label as security and @ mention @gitlab-com/gl-security/appsec
  • The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
  • Security reports checked/validated by a reviewer from the AppSec team

Merge request reports