Open Stack

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.
'''

http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html

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