<div dir="ltr">Referring to the original question<div><br></div><div>'<span style="font-size:12.8px">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.'</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">The metadata service is as secure as underlaying infrastructure supporting it.</span><br></div><div><span style="font-size:12.8px">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.</span></div><div><span style="font-size:12.8px">My recommendation it to ensure that your APIs and supporting infra are secured according to your specific requirements. </span><span style="font-size:12.8px">You may want to develop your own threat model, analyse risks relevant to your infrastructure, apply appropriate controls. </span><span style="font-size:12.8px">You may find security guide useful, <a href="https://docs.openstack.org/security-guide/">https://docs.openstack.org/security-guide/</a></span></div><div><br></div><div><span style="font-size:12.8px"><br></span></div><div><br></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 4, 2017 at 8:12 AM, Gary Kotton <span dir="ltr"><<a href="mailto:gkotton@vmware.com" target="_blank">gkotton@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
You can configure the metadata service to be secure. You just need to make sure that nova is configured correctly. FYI - <a href="https://github.com/openstack/neutron/blob/master/neutron/conf/agent/metadata/config.py#L68" rel="noreferrer" target="_blank">https://github.com/openstack/<wbr>neutron/blob/master/neutron/<wbr>conf/agent/metadata/config.py#<wbr>L68</a><br>
Thanks<br>
Gary<br>
<span class=""><br>
On 10/4/17, 7:01 AM, "Joshua Harlow" <<a href="mailto:harlowja@fastmail.com">harlowja@fastmail.com</a>> wrote:<br>
<br>
I would treat the metadata service as not secure.<br>
<br>
From amazon docs (equivalent can be said about openstack):<br>
<br>
'''<br>
Important<br>
<br>
Although you can only access instance metadata and user data from within<br>
the instance itself, the data is not protected by cryptographic methods.<br>
Anyone who can access the instance can view its metadata. Therefore, you<br>
should take suitable precautions to protect sensitive data (such as<br>
long-lived encryption keys). You should not store sensitive data, such<br>
as passwords, as user data.<br>
'''<br>
<br>
</span> <a href="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=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.<wbr>com/v2/url?u=http-3A__docs.<wbr>aws.amazon.com_AWSEC2_latest_<wbr>UserGuide_ec2-2Dinstance-<wbr>2Dmetadata.html&d=DwIGaQ&c=<wbr>uilaK90D4TOVoH58JNXRgQ&r=<wbr>PMrZQUSXojEgJQPh7cZrz1Lvja0OwA<wbr>stg0U82FalZrw&m=<wbr>6hYo6Fh9CLmjqptic1Jk22ZN3jgrnj<wbr>OSs2p_8Opv7oo&s=XOsLXFFKlrL9E_<wbr>B_lgNqvvqvTOKic_rIAJpQdVTMryg&<wbr>e=</a><br>
<div class="HOEnZb"><div class="h5"><br>
So private keys would be a no-no, public keys would be ok (since they<br>
are public anyway).<br>
<br>
Giuseppe de Candia wrote:<br>
> Hi Folks,<br>
><br>
><br>
> Are there any documented conventions regarding the security model for<br>
> MetaData?<br>
><br>
><br>
> Note that CloudInit allows passing user and ssh service public/private<br>
> keys via MetaData service (or ConfigDrive). One assumes it must be<br>
> secure, but I have not found a security model or documentation.<br>
><br>
><br>
> My understanding of the Neutron reference implementation is that<br>
> MetaData requests are HTTP (not HTTPS) and go from the VM to the<br>
> MetaData proxy on the Network Node (after which they are proxied to Nova<br>
> meta-data API server). The path from VM to Network Node using HTTP<br>
> cannot guarantee confidentiality and is also susceptible to<br>
> Man-in-the-Middle attacks.<br>
><br>
> Some Neutron drivers proxy Metadata requests locally from the node<br>
> hosting the VM that makes the query. I have mostly seen this<br>
> presented/motivated as a way of removing dependency on the Network node,<br>
> but it should also increase security. Yet, I have not seen explicit<br>
> discussions of the security model, nor any attempt to set a standard for<br>
> security of the meta-data.<br>
><br>
> Finally, there do not seem to be granular controls over what meta-data<br>
> is presented over ConfigDrive (when enabled) vs. meta-data REST API. As<br>
> an example, Nova vendor data is presented over both, if both are<br>
> enabled; config drive is presumably more secure.<br>
><br>
> thanks,<br>
> Pino<br>
><br>
><br>
> ______________________________<wbr>______________________________<wbr>______________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div style="color:rgb(136,136,136);font-size:12.8000001907349px">Adam Heczko</div><div style="color:rgb(136,136,136);font-size:12.8000001907349px">Security Engineer @ Mirantis Inc.</div></div></div>
</div>