Open Stack

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.




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!



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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160330/0e406c2e/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/0e406c2e/attachment.gif>