[Openstack] [OpenStack] [Keystone] Is it possible to cache ec2 credentials?

[Alexandr Porunov]

Hello,

I want to use ec2 credentials. But I don't know about it's route of
validating. Is it much slower than tokens validation?

I don't know exactly what is the route of ec2 validation but here is what I
think:
1)  Service node accept a request with ec2 credentials.
2) Service asks Keystone to check credentials.
3) Keystone search credentials in MySQL.
4) If credentials are the same as in MySQL then Keystone will return OK to
the service.

If the route is the same as I described above then the performance will be
really bad because we will go and check credentials in MySQL for each
request.

Is it possible to cache ec2 credentials on the Keystone side or on the
Service side to don't ask MySQL for each request?

Best regards,
Alexandr
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [OpenStack] VM start up with no route rules

[Eugen Block]

Does your VM's interface also have DHCP enabled? If it's configured to  
have a static address, it won't be changed by dhcp. Have you used the  
image outside of heat and did it work with dhcp for a single VM?



Zitat von "Xu, Rongjie (Nokia - CN/Hangzhou)" :


Hi,

I am launch a heat stack on top of Mirantis OpenStack Mitaka.  
However, I see no route rules (output of command 'ip route' is  
empty) inside VM, which make the VM cannot get the metadata from  
metadata server. Basically, the VM is connected to a management  
network (192.168.1.0/24 DHCP enabled).


How can I debug this problem? Is it something wrong with Neutron? Thanks.



Best Regards
Xu Rongjie (Max)
Mobile:18658176819




--
Eugen Block voice   : +49-40-559 51 75
NDE Netzdesign und -entwicklung AG  fax : +49-40-559 51 77
Postfach 61 03 15
D-22423 Hamburg e-mail  : ebl...@nde.ag

Vorsitzende des Aufsichtsrates: Angelika Mozdzen
  Sitz und Registergericht: Hamburg, HRB 90934
  Vorstand: Jens-U. Mozdzen
   USt-IdNr. DE 814 013 983


___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [openstack-dev] [OSSN-0074] Nova metadata service should not be used for sensitive information

[Jeremy Stanley]

On 2017-01-19 09:34:21 -0500 (-0500), Steve Gordon wrote:
[...]
> Does this configuration directive provide any mitigation for this
> issue?:
> 
> "use_forwarded_for = False (BoolOpt) Treat X-Forwarded-For
> as the canonical remote address. Only enable this if you have a
> sanitizing proxy."
> 
> Just given its name and stated purpose it seems conspicuous by its
> absence in this OSSN (that is, even if it provides no mitigation
> at all I would have expected to see that noted)?
[...]

I agree it's unfortunate this was omitted in the discussion. If you
follow the original bug report[*], it's only applicable to
environments which set use_forwarded_for = True. The report can be
reduced to the following summary: If you configure nova's metadata
service to rely on X-Forwarded-For (by setting use_forwarded_for =
True) so that you can put a proxy in front of it, then you need to
make sure your network is correctly designed such that untrusted
systems are not allowed to connect directly to the service without
going through your proxy (and also make sure your proxy correctly
rewrites any existing X-Forwarded-For headers it may receive rather
than passing them through untouched).

[*] https://launchpad.net/bugs/1563954
-- 
Jeremy Stanley


signature.asc
Description: Digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [OSSN-0074] Nova metadata service should not be used for sensitive information

[Steve Gordon]

- Original Message -
> From: "Luke Hinds" 
> To: openstack@lists.openstack.org, openstack-...@lists.openstack.org
> Sent: Monday, December 19, 2016 4:26:24 AM
> Subject: [Openstack] [OSSN-0074] Nova metadata service should not be used for 
> sensitive information
> 
> OpenStack Security Note: 0074
> 
> Nova metadata service should not be used for sensitive information
> 
> ---
> 
> ### Summary ###
> A recent security report has highlighted how users may be using the
> metadata service to store security sensitive information.
> 
> The Nova metadata service should not be considered a secure repository
> of confidential information required by compute instances.
> 
> ### Affected Services / Software ###
> Nova, All Versions
> 
> ### Discussion ###
> A recent vulnerability report for Nova stated that the metadata service
> will obey the `X-Forwarded-For` HTTP header. This header is often
> supplied by proxies so that the end service can identify which IP the
> request originated from.
> 
> The Nova metadata service typically uses the source IP address of the
> incoming request to respond with the appropriate data for the compute
> instance making the request. This is a sort of weak authentication,
> designed to ensure that metadata for one tenant isn't accidentally
> provided to another.
> 
> If the request contains a `X-Forwarded-For` HTTP header then the
> metadata service will use that for the source authentication rather than
> the actual TCP/IP source.

Hi Luke,

Does this configuration directive provide any mitigation for this issue?:

"use_forwarded_for = False (BoolOpt) Treat X-Forwarded-For as the 
canonical remote address. Only enable this if you have a sanitizing proxy."

Just given its name and stated purpose it seems conspicuous by its absence in 
this OSSN (that is, even if it provides no mitigation at all I would have 
expected to see that noted)?

Thanks,

Steve

> An attacker with access to a compute instance in the cloud could send a
> request to the metadata service and include the `X-Forwarded-For` header
> in order to effectively spoof their source and cause the metadata
> service to provide information that should not have been provided to
> that instance.
> 
> Consider the following:
> Alice creates a compute instance. She places the root password for that
> instance in the metadata service. The instance is assigned a 10.1.2.2
> IP address. Alice believes that the root password for her instance is
> safe within the metadata service.
> 
> Alice retrieves metadata by running a command similar to:
> `curl http://169.254.169.254/latest/meta-data
> `
> this will retrieve any metadata stored for Alice's compute instance,
> which has an IP address of 10.1.2.2
> 
> Bob has a compute instance with IP address 10.1.9.9 however Bob wants
> access to the metadata for Alice's compute instance. If Bob runs a
> similar command to Alice, but includes a customer header as below, he
> will get access to all of Alice's metadata, including the root password
> she chose to store there:
> `curl -H "X-Forwarded-For:
> 10.1.2.2" http://169.254.169.254/latest/meta-data
> `
> 
> The Nova metadata service is a useful utility within OpenStack but
> clearly not intended as a strongly authenticated system for storing
> sensitive data such as private keys or passwords.
> 
> ### Recommended Actions ###
> The metadata service should not be used to store sensitive information.
> 
> The IP forwarding issue is not a defect of itself, it exists to allow
> the metadata service to provide IP addresses for instances that are
> behind a proxy as may be the case in more complex deployments.
> 
> Cloud users who have a requirement to store sensitive information that
> compute instances require for operation should instead look to the
> Config drive to provide this service. It's operation is much more
> tightly bound to individual compute instances.
> 
> Where use of config drive is not an option, operators should consider
> other mitigations such as placing a proxy in front of the metadata service
> which can filter out these sorts of malicious activities.
> 
> ### Contacts / References ###
> Author: Robert Clark, IBM
> This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0074
> Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1563954
> 
> Mailing List : [Security] tag on openstack-...@lists.openstack.org
> OpenStack Security Group : https://launchpad.net/~openstack-ossg
> 
> Config Drive
> : http://docs.openstack.org/user-guide/cli-config-drive.html
> 
> 
> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-

Re: [Openstack] How to troubleshoot Security Group rules

[Vimal Kumar]

Hi,

Is the rules implemented in the iptables of the node (I am running
all-in-one, LinuxBridge setup), or is it implemented in the iptables of a
separate network namespace?

On Thu, Jan 19, 2017 at 1:27 PM, Melvin Hillsman 
wrote:

> If you are running an all-in-one/single node deployment, your security
> groups are implemented via iptables on that node. If you had a multi-node
> setup, security group rules would show up on the compute hosts.
>
> On Thu, Jan 19, 2017 at 12:47 AM, Vimal Kumar  wrote:
>
>> Hi!
>>
>> How can I troubleshoot issues related to security groups? It is probably
>> getting implemented via iptables but where? In the host iptables, or inside
>> network namespace, or inside instance itself? I am running a single-node
>> Newton.
>>
>> I am looking for a way to check whether the rules in my security group is
>> actually being implemented or not.
>>
>> Thank you!
>>
>> Regards,
>>
>> Vimal
>>
>> ___
>> Mailing list: http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>> Post to : openstack@lists.openstack.org
>> Unsubscribe : http://lists.openstack.org/cgi
>> -bin/mailman/listinfo/openstack
>>
>>
>
>
> --
> Kind regards,
>
> Melvin Hillsman
> Ops Technical Lead
> OpenStack Innovation Center
>
> mrhills...@gmail.com
> phone: (210) 312-1267
> mobile: (210) 413-1659
> http://osic.org
>
> Learner | Ideation | Belief | Responsibility | Command
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack