Open Stack

Referring to the original question

'Note that CloudInit allows passing user and ssh service public/private
keys via MetaData service (or ConfigDrive). One assumes it must be secure,
but I have not found a security model or documentation.'

The metadata service is as secure as underlaying infrastructure supporting
it.
Now take into account that Nova communicates with Neutron via API, you
typically enter your SSH public (not private) key with API etc. Clearly API
endpoint security and all API supporting infra are key players here.
My recommendation it to ensure that your APIs and supporting infra are
secured according to your specific requirements. You may want to develop
your own threat model, analyse risks relevant to your infrastructure, apply
appropriate controls. You may find security guide useful,
https://docs.openstack.org/security-guide/





On Wed, Oct 4, 2017 at 8:12 AM, Gary Kotton <gkotton at vmware.com> wrote:

> Hi,
> You can configure the metadata service to be secure. You just need to make
> sure that nova is configured correctly. FYI -
> https://github.com/openstack/neutron/blob/master/neutron/
> conf/agent/metadata/config.py#L68
> Thanks
> Gary
>
> On 10/4/17, 7:01 AM, "Joshua Harlow" <harlowja at fastmail.com> wrote:
>
>     I would treat the metadata service as not secure.
>
>      From amazon docs (equivalent can be said about openstack):
>
>     '''
>     Important
>
>     Although you can only access instance metadata and user data from
> within
>     the instance itself, the data is not protected by cryptographic
> methods.
>     Anyone who can access the instance can view its metadata. Therefore,
> you
>     should take suitable precautions to protect sensitive data (such as
>     long-lived encryption keys). You should not store sensitive data, such
>     as passwords, as user data.
>     '''
>
>     https://urldefense.proofpoint.com/v2/url?u=http-3A__docs.
> aws.amazon.com_AWSEC2_latest_UserGuide_ec2-2Dinstance-
> 2Dmetadata.html&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=
> PMrZQUSXojEgJQPh7cZrz1Lvja0OwAstg0U82FalZrw&m=
> 6hYo6Fh9CLmjqptic1Jk22ZN3jgrnjOSs2p_8Opv7oo&s=XOsLXFFKlrL9E_
> B_lgNqvvqvTOKic_rIAJpQdVTMryg&e=
>
>     So private keys would be a no-no, public keys would be ok (since they
>     are public anyway).
>
>     Giuseppe de Candia wrote:
>     > Hi Folks,
>     >
>     >
>     > Are there any documented conventions regarding the security model for
>     > MetaData?
>     >
>     >
>     > Note that CloudInit allows passing user and ssh service
> public/private
>     > keys via MetaData service (or ConfigDrive). One assumes it must be
>     > secure, but I have not found a security model or documentation.
>     >
>     >
>     > My understanding of the Neutron reference implementation is that
>     > MetaData requests are HTTP (not HTTPS) and go from the VM to the
>     > MetaData proxy on the Network Node (after which they are proxied to
> Nova
>     > meta-data API server). The path from VM to Network Node using HTTP
>     > cannot guarantee confidentiality and is also susceptible to
>     > Man-in-the-Middle attacks.
>     >
>     > Some Neutron drivers proxy Metadata requests locally from the node
>     > hosting the VM that makes the query. I have mostly seen this
>     > presented/motivated as a way of removing dependency on the Network
> node,
>     > but it should also increase security. Yet, I have not seen explicit
>     > discussions of the security model, nor any attempt to set a standard
> for
>     > security of the meta-data.
>     >
>     > Finally, there do not seem to be granular controls over what
> meta-data
>     > is presented over ConfigDrive (when enabled) vs. meta-data REST API.
> As
>     > an example, Nova vendor data is presented over both, if both are
>     > enabled; config drive is presumably more secure.
>     >
>     > thanks,
>     > Pino
>     >
>     >
>     > ____________________________________________________________
> ______________
>     > 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
>



-- 
Adam Heczko
Security Engineer @ Mirantis Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171004/3646c01a/attachment.html>