[openstack-dev] [magnum] Discuss the blueprint"support-private-registry"

Ricardo Rocha rocha.porto at gmail.com
Wed Mar 30 14:59:17 UTC 2016


Hi.

On Wed, Mar 30, 2016 at 4:20 PM, Kai Qiang Wu <wkqwu at cn.ibm.com> wrote:

> I agree to that support-private-registry should be secure. As insecure
> seems not much useful for production use.
> Also I understood the point setup related CA could be diffcult than normal
> HTTP, but we want to know if
> https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig
>
> Could address the issue and make templates clearer to understood ? If
> related patch or spec proposed, we are glad to review and make it better.
>

Yes, some local customization of the node setup would be great and help
with the CA setup - we're willing to implement that blueprint.

Cheers,
Ricardo


>
>
>
>
> Thanks
>
> Best Wishes,
>
> --------------------------------------------------------------------------------
> Kai Qiang Wu (吴开强 Kennan)
> IBM China System and Technology Lab, Beijing
>
> E-mail: wkqwu at cn.ibm.com
> Tel: 86-10-82451647
> Address: Building 28(Ring Building), ZhongGuanCun Software Park,
> No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193
>
> --------------------------------------------------------------------------------
> Follow your heart. You are miracle!
>
> [image: Inactive hide details for Ricardo Rocha ---30/03/2016 09:09:14
> pm---Hi. On Wed, Mar 30, 2016 at 3:59 AM, Eli Qiao <liyong.qiao@]Ricardo
> Rocha ---30/03/2016 09:09:14 pm---Hi. On Wed, Mar 30, 2016 at 3:59 AM, Eli
> Qiao <liyong.qiao at intel.com> wrote:
>
> From: Ricardo Rocha <rocha.porto at gmail.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>
> Date: 30/03/2016 09:09 pm
> Subject: Re: [openstack-dev] [magnum] Discuss the blueprint
> "support-private-registry"
> ------------------------------
>
>
>
> Hi.
>
> On Wed, Mar 30, 2016 at 3:59 AM, Eli Qiao <liyong.qiao at intel.com> wrote:
> >
> > Hi Hongbin
> >
> > Thanks for starting this thread,
> >
> >
> >
> > I initial propose this bp because I am in China which is behind China
> great
> > wall and can not have access of gcr.io directly, after checking our
> > cloud-init script, I see that
> >
> > lots of code are *hard coded* to using gcr.io, I personally though this
> is
> > not good idea. We can not force user/customer to have internet access in
> > their environment.
> >
> > I proposed to use insecure-registry to give customer/user (Chinese or
> whom
> > doesn't have gcr.io access) a chance to switch use their own
> > insecure-registry to deploy
> > k8s/swarm bay.
> >
> > For your question:
> >>      Is the private registry secure or insecure? If secure, how to
> handle
> >> the authentication secrets. If insecure, is it OK to connect a secure
> bay to
> >> an insecure registry?
> > An insecure-resigtry should be 'secure' one, since customer need to
> setup it
> > and make sure it's clear one and in this case, they could be a private
> > cloud.
> >
> >>  Should we provide an instruction for users to pre-install the private
> >> registry? If not, how to verify the correctness of this feature?
> >
> > The simply way to pre-install private registry is using insecure-resigtry
> > and docker.io has very simple steps to start it [1]
> > for other, docker registry v2 also supports using TLS enable mode but
> this
> > will require to tell docker client key and crt file which will make
> > "support-private-registry" complex.
> >
> > [1] https://docs.docker.com/registry/
> > [2]https://docs.docker.com/registry/deploying/
>
> 'support-private-registry' and 'allow-insecure-registry' sound different
> to me.
>
> We're using an internal docker registry at CERN (v2, TLS enabled), and
> have the magnum nodes setup to use it.
>
> We just install our CA certificates in the nodes (cp to
> etc/pki/ca-trust/source/anchors/, update-ca-trust) - had to change the
> HEAT templates for that, and submitted a blueprint to be able to do
> similar things in a cleaner way:
> https://blueprints.launchpad.net/magnum/+spec/allow-user-softwareconfig
>
> That's all that is needed, the images are then prefixed with the
> registry dns location when referenced - example:
> docker.cern.ch/my-fancy-image.
>
> Things we found on the way:
> - registry v2 doesn't seem to allow anonymous pulls (you can always
> add an account with read-only access everywhere, but it means you need
> to always authenticate at least with this account)
> https://github.com/docker/docker/issues/17317
> - swarm 1.1 and kub8s 1.0 allow authentication to the registry from
> the client (which was good news, and it works fine), handy if you want
> to push/pull with authentication.
>
> Cheers,
>  Ricardo
>
> >
> >
> >
> > On 2016年03月30日 07:23, Hongbin Lu wrote:
> >
> > Hi team,
> >
> >
> >
> > This is the item we didn’t have time to discuss in our team meeting, so I
> > started the discussion in here.
> >
> >
> >
> > Here is the blueprint:
> > https://blueprints.launchpad.net/magnum/+spec/support-private-registry .
> Per
> > my understanding, the goal of the BP is to allow users to specify the
> url of
> > their private docker registry where the bays pull the kube/swarm images
> (if
> > they are not able to access docker hub or other public registry). An
> > assumption is that users need to pre-install their own private registry
> and
> > upload all the required images to there. There are several potential
> issues
> > of this proposal:
> >
> > ·         Is the private registry secure or insecure? If secure, how to
> > handle the authentication secrets. If insecure, is it OK to connect a
> secure
> > bay to an insecure registry?
> >
> > ·         Should we provide an instruction for users to pre-install the
> > private registry? If not, how to verify the correctness of this feature?
> >
> >
> >
> > Thoughts?
> >
> >
> >
> > Best regards,
> >
> > Hongbin
> >
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> > --
> > Best Regards, Eli Qiao (乔立勇)
> > Intel OTC China
> >
> >
> >
> __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160330/c07a9b13/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160330/c07a9b13/attachment.gif>


More information about the OpenStack-dev mailing list