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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
