Re: [openstack-dev] Security of Meta-Data
Hi Folks, I'm still processing all this information - thanks for your help! --Pino On Wed, Oct 4, 2017 at 7:58 AM, Jeremy Stanley wrote: > On 2017-10-04 10:47:02 +0100 (+0100), Luke Hinds wrote: > [...] > > The recommendation is not to use metadata for security sensitive > > data (its possible to spoof by setting a X-Forwarded header), > > please see the following OpenStack Security Note on the topic: > > > > https://wiki.openstack.org/wiki/OSSN/OSSN-0074 > > Well, it's possible as long as the environment is badly > designed/configured: you deployed nova to expect a proxy, but then > gave guest instances a way to reach the metadata API without going > through that proxy. So while it's definitely a risk to be aware of, > it come pretty close to the need Sean mentions for "solid network > security on the path between your guests and your nova-API." > -- > Jeremy Stanley > > __ > 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
Re: [openstack-dev] Security of Meta-Data
On 2017-10-04 10:47:02 +0100 (+0100), Luke Hinds wrote: [...] > The recommendation is not to use metadata for security sensitive > data (its possible to spoof by setting a X-Forwarded header), > please see the following OpenStack Security Note on the topic: > > https://wiki.openstack.org/wiki/OSSN/OSSN-0074 Well, it's possible as long as the environment is badly designed/configured: you deployed nova to expect a proxy, but then gave guest instances a way to reach the metadata API without going through that proxy. So while it's definitely a risk to be aware of, it come pretty close to the need Sean mentions for "solid network security on the path between your guests and your nova-API." -- Jeremy Stanley signature.asc Description: Digital signature __ 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
Re: [openstack-dev] Security of Meta-Data
There is an assumption that you've got solid network security on the path between your guests and your nova-API. Either because you've got a secure network path, or you run the neutron proxy server on the host itself, and so this is a no hop call. Because this is a bootstrapping problem, and the guests are coming up blank and *asking* the service how they should be configured, it's kind of hard to have generically better security than that. A lot of how that path is configured is very specific to deployment's networking setup and topology, so the options are on the table without a specific recommendation. If you still have concerns about that, it's always possible to bake your own config management daemon into your images, and do more sensitive data pulled via a certificate secured model. You do then have to manage certificate rotation in guest images, but that moves the bootstrapping problem elsewhere. -Sean On 10/03/2017 06:00 PM, 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 > -- Sean Dague http://dague.net __ 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
Re: [openstack-dev] Security of Meta-Data
On Tue, Oct 3, 2017 at 11:00 PM, Giuseppe de Candia < giuseppe.decan...@gmail.com> 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 > > > The recommendation is not to use metadata for security sensitive data (its possible to spoof by setting a X-Forwarded header), please see the following OpenStack Security Note on the topic: https://wiki.openstack.org/wiki/OSSN/OSSN-0074 __ 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
Re: [openstack-dev] Security of Meta-Data
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 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" 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-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 > > > __ > 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 > -- Adam Heczko Security Engineer @ Mirantis Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstac
Re: [openstack-dev] Security of Meta-Data
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" 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-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 __ 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
Re: [openstack-dev] Security of Meta-Data
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
[openstack-dev] Security of Meta-Data
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
