Re: [Openstack-operators] [Glance] Default policy in policy.json
On 06/20/2016 10:09 PM, Michael Richardson wrote: On Fri, 17 Jun 2016 16:27:54 + Also which would be preferred "role:admin" or "!"? Brian points out on [1] that "!" would in effect, notify the admins that a policy is not defined as they would be unable to preform the action themselves. +1 for "!" (and brilliant that the Glance project are being proactive on this front; hopefully the others will follow suit). Cheers, Michael Richardson. Thanks, Niall 1. https://review.openstack.org/#/c/330443/ ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators We are workging on making the "admin and is_admin_project" a reality. THat should be the default, but we can submit that once things are working. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [keystone] Federation, domain mappings and v3 policy.json
On 06/13/2016 07:08 PM, Marc Heckmann wrote: Hi, I currently have a lab setup using SAML2 federation with Microsoft ADFS. The federation part itself works wonderfully. However, I'm also trying to use the new project as domains feature along with the Keystone v3 sample policy.json file for Keystone: The idea is that I should be able to map users who are in a specific group in Active Directory to the admin role in a specific domain. This should work for Keystone with the sample v3 policy (let's ignore problems with the admin role in other projects such as Nova). In this case I'm using the new project as domains feature, but I suspect that the problem would apply to regular domains as well. The mapping works properly with the important caveat that the user domain does not match the domain of the project(s) that I'm assigning the admin role to. Users who come in from Federation always belong to the "Federated" domain. This is the case even if I pre-create the users locally in a specific domain. This breaks sample v3 policy.json because the rules expect the user's domain to match the project's domain. Does anyone know if there is anyway to achieve what I'm trying to do when using Federation? Can you post your mapping file? Might be easier to tell from that what you are trying to do? Thanks in advance. -m ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Nova 2.1 and user permissions in the policy file
On 05/23/2016 11:02 AM, Sean Dague wrote: On 05/23/2016 10:24 AM, Tim Bell wrote: Quick warning for those who are dependent on the "user_id:%(user_id)s" syntax for limiting actions by user. According to https://bugs.launchpad.net/nova/+bug/1539351, this behavior was apparently not intended according to the bug report feedback. The behavior has changed from v2 to v2.1 and the old syntax no longer works. v2 to v2.1 of what? Well, the behavior changes with the backend code base. By mitaka the default backend code for both is the same. And the legacy code base is about to be removed. This feature (policy enforcement by user_id) was 100% untested, which is why it never ended up in the new API stack. Being untested setting owner: 'user_id: %(user_id)s' might have some really unexpected results because not everything has a user_id. There can be security implications also so I’d recommend those using this current v2 feature to review the bug to understand the potential impacts as clouds enable v2.1. While I understand from the bug report what your use case is now, I'm kind of wondering what the shared resources / actions of these 150 people are in this project. Are they all in the same project for other reasons? My sediments exactly. In cloud, you should never be looking at a user id for policy. It should be possible to always have more than one user perform an action, and enforce policy on the project_id. The one exception for this is Barbican managing cryptographic secrets for a user's Identity. And yes, I meant to say sediments. I'm trying to be part of the solution. -Sean ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-ansible] centos support
On 02/18/2016 01:01 PM, Abel Lopez wrote: We talked a bit about making OSAD 'EL' compatible, but we ultimately decided against it. There were various architectural differences that made it not worth the effort. I don't know if anyone else was seriously considering the work. Would highly recommend looking at Kolla instead. It uses Ansible, and deploys via containers. I'm in love with the project, and seriously think it is the future of OpenStack. http://adam.younglogic.com/2016/02/holla-kolla/ On Feb 18, 2016, at 9:41 AM, Wade Hollerwrote: Hi All, Could someone let me know if a person / org has taken ownership of this yet? I have heard it talked about but haven't seen where it's owned or officially happening yet. My primary customer is will to dedicate a decent chunk of my time investigating and I don't want to reinvent the wheel(s). Cheers Wade ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [ceilometer][keystone][billing] RBAC restrictions of Ceilometer's Event API prevents billing of Openstack cloud
On 12/07/2015 05:01 AM, Christian Brinker wrote: Hi, my company is currently starting to implement a public Openstack cloud. I am part of the developer team creating a billing system towards our customers. We want to use Ceilometer's Event API (Liberty release) to retreive the usage information (as /v2/events) of our customers projects(aka tenants). Unfortunately, the RBAC filter prevents REST calls towards the /v2-Web-API from users who are not member of the project (or are their admin). But adding a user to all projects with a distinc ceilometer-reader role or admin role seems not fourtunate to us because to want to serve admin role users to their own domain to each customer. So the ceilometer-reader user could be removed by a customer. Due to this, we ran into some kind of deadlock of good solutions and would be happy to get any help: - Is there another/common way to retrieve the event based usage information in a way to generate billing information? For example volume A was created at t1 and deleted at t2. - Is there a way to get a project scope token from keystone through some kind of cloud admin user which is not part of the project? - Is there a way to change Ceilometers policy.json in a way to retrieve data from all projects with a admin on the default project or someone similiar? See the commit that just merged: https://review.openstack.org/#/c/240719/ You could create a role called "observer" or "auditor" on the admin project, and modify the policy files for the services you want so that users with "auditor" with tokens that have "is_admin_project" set can read the data for that API. Can you enumerate the APIS you want to call this way? Thanks for your efforts. Greetings, Christian Brinker ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-dev] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka
On 12/07/2015 06:53 PM, Thomas Goirand wrote: On 12/01/2015 07:57 AM, Steve Martinelli wrote: Trying to summarize here... - There isn't much interest in keeping eventlet around. - Folks are OK with running keystone in a WSGI server, but feel they are constrained by Apache. - uWSGI could help to support multiple web servers. My opinion: - Adding support for uWSGI definitely sounds like it's worth investigating, but not achievable in this release (unless someone already has something cooked up). - I'm tempted to let eventlet stick around another release, since it's causing pain on some of our operators. - Other folks have managed to run keystone in a web server (and hopefully not feel pain when doing so!), so it might be worth getting technical details on just how it was accomplished. If we get an OK from the operator community later on in mitaka, I'd still be OK with removing eventlet, but I don't want to break folks. stevemar From: John Dewey100% agree. We should look at uwsgi as the reference architecture. Nginx/Apache/etc should be interchangeable, and up to the operator which they choose to use. Hell, with tcp load balancing now in opensource Nginx, I could get rid of Apache and HAProxy by utilizing uwsgi. John The main problem I see with running Keystone (or any other service) in a web server, is that *I* (as a package maintainer) will loose the control over when the service is started. Let me explain why that is important for me. In Debian, many services/daemons are run, then their API is used by the package. In the case of Keystone, for example, it is possible to ask, via Debconf, that Keystone registers itself in the service catalog. If we get Keystone within Apache, it becomes at least harder to do so. The other issue is that if all services are sharing the same web server, restarting the web server restarts all services. Or, said otherwise: if I need to change a configuration value of any of the services served by Apache, I will need to restart them all, which is very annoying: I very much prefer to just restart *ONE* service if I need. Also, something which we learned the hard way at Mirantis: it is *very* annoying that Apache restarts every Sunday morning by default in distributions like Ubuntu and Debian (I'm not sure for the other distros). No, the default config of logrotate and Apache can't be changed in distros just to satisfy OpenStack users: there's other users of Apache in these distros. Then, yes, uWSGI becomes a nice option. I used it for the Barbican package, and it worked well. Though the uwsgi package in Debian isn't very well maintained, and multiple times, Barbican could have been removed from Debian testing because of RC bugs against uWSGI. So, all together, I'm a bit reluctant to see the Eventlet based servers going away. If it's done, then yes, I'll work around it. Though I'd prefer if it didn't. You can run one instance of Apache for each service, and have the listen on different ports. Its not how the distros set up apache, but then again, the distros only set up Eventlet with the work we;'ve done. Eventlet has threading issues I'd rather not debug anymore. It is also my view that it's up to the deployers to decide how they want to implement things. For many small use cases, Eventlet performs well enough. And for these, Apache is still a better approach, all things considered. Every way has some pain...we are trying to chose the lesser. Finally, one thing which I never understood: if Eventlet is bad as an HTTP server, can't we use anything else written in Python? Isn't it possible to write a decent HTTP server in Python? Why are we forced into just Eventlet for doing the job? I haven't searched around, but there must be loads of alternatives, no? Crypto. Crypto should not be done in Python. Also, GIL and multi threading make it hard to do in Python. Hence the userland threading approach. Which has an impact on all blocking IO calls. There are many ways to get what you want. Each service in their own container is probably the one that maps closest to the type of insulation we'd like to see. Each in their own VM probably makes sense for a non-trivial sized cloud. Cheers, Thomas Goirand (zigo) ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] "Master" keystone and "sub" keystone
On 09/26/2015 11:19 PM, RunnerCheng wrote: Hi All, I'm a newbie of keystone, and I'm doing some research about it recently. I have a question about how to deploy it. The scenario is on below: One comany has one headquarter dc and 5 sub dc locate in different cities. We want to deploy separate OpenStack with "sub" keystone at the sub dc, and want to deploy one "master" keystone at headquarter dc. We want to manage all users, roles and tenants etc on the "master" keystone, however we want the end-user can authenticate with the "sub" keystone where he or she is locate. Use LDAP for the users, don't keep them in Keystone. Replicate roles, projects etc from master to sub. Use Fernet tokens. Replicate revocation events both ways. Is anyone understant this scenario? How to realize it without additionaly development? Thanks in advance! Sam Cheng ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Dynamic Policy
On 08/05/2015 12:01 PM, Kris G. Lindgren wrote: We ran into this as well. What we did is create an external to keystone api, that we expose to our end users via a UI. The api will let user create projects (with a specific defined quota) and also add users with the project admins role to the project. Those admins can add/remove users from the project and also delete the project. You can also be a member, where you have the ability to spin up vm's under the project but not add/remove users or remove the project. We also do some other stuff to clean up items in a project before its deleted. We are working to move this functionality out of the current external API and into keystone. I believe we were going to look at waffle-haus to add a paste filter to intercept the project create calls and do the needful. We also modified the policy.json files for the services that we care about to add the new roles that we created. Were you working around limitation by building an external system to Keystone to provide a means of delegating the ability to assign roles? Would you have wanted to synchronize the roles you defined in your Keytone instance with the policy files directly? Did you have to modify policy files beyond the Keystone policy file? Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 8/5/15, 9:39 AM, Fox, Kevin M kevin@pnnl.gov wrote: As an Op, I've ran into this problem and keep running into it. I would very much like a solution. Its also quite related to the nova instance user issue I've been working on, that's needed by the App Catalog project. So, yes, please keep fighting the good fight. Thanks, Kevin From: Adam Young [ayo...@redhat.com] Sent: Wednesday, August 05, 2015 7:50 AM To: openstack-operators@lists.openstack.org Subject: [Openstack-operators] Dynamic Policy How do you delegate the ability to delegate? Lets say you are running a large cloud (purely hypothetical here) and you want to let a user manage their own project. They are admin but they should be able to invite or eject people. In order to do this, an ordinary user needs to be able to make a role assignment. However, Keystone does not support this today: if you are admin somewhere, you are admin everywhere: https://bugs.launchpad.net/keystone/+bug/968696 Access control in OpenStack is controlled by Policy. An informal survey of operators shows that most people run with the stock policies such as the Nova policy: http://git.openstack.org/cgit/openstack/nova/tree/etc/nova/policy.json In order to scope admin to the proejct, we would need to have rules that enforce this scoping: Evey rule should check that the project_id in the token provided matches the project_id of the resource of the API. If we manage to get the policy files rewritten this way, We then need a way to limit what roles a user can assign.The default mechanism would say that a user needs to have an administrative role on the project (or domain) that they want to assign the role on. I don't think anything I've written thus far is controversial. Then, why has it not happened yet? here are the list of problems we need to solve: 1. Operators expect the existing policy files to work as is. Changing them will break workflow. 2. If everything is scoped, we need a way to delete resources left orphan when a project is deleted from Keystone and the service does not get the notification (or know how to handle it). Of the two, I think the top one is the more difficult to solve. Scoping everything can be handled via one of two mechanism; either allow a power-admin user to get a token scoped to some random project (even if it has been deleted) or allow a token scoped to an administrative project to also delete resources for a random project. Dealing with the existing policy file issues is trickier, and that is the real reason for the Dynamic Policy approach: give the endpoints the ability to fetch their policy files from Keystone. If policy goes from being a configuration file to data, it is managed outside of the configuration management tools, and becomes much more fluid. This has risks, and should be an Opt-In mechanism. Fetching the policy files from Keystone also provides the start of a richer set of management for policy rules. Currently, each of the stock policy files exists only in their seperate git repos. There is no sharing of policy rules across projects. If the policy files were managed, rule by rule, from a centralized repository, rules could be shared, providing, among other things, the ability to enforce hierarchical roles, roles namespaced to a service, and other, richer policy management. Feedback on this approach from operators is greatly appreciated. I need to justify the effort that would go in to making this happen, so if you want it, speak up. If, on the other hand, you feel that this is needlessly
Re: [Openstack-operators] OSAD for RHEL
On 07/10/2015 02:25 PM, Kevin Carter wrote: To be clear the present OSAD project really has no intention to bring package based installations of OpenStack. We'd certainly not reject the idea and wouldn't mind having an implementation spec for it but all of our current tooling and design principles have been based on the fact that we've move away from distro packages and on to upstream source as it pertains to OpenStack. The system as it stands today creates an internal repository of built wheels for your environment and all of the OpenStack services are installed within LXC containers, where possible and it makes sense. The installation of these bits comes from the internal wheel repository and uses pip and all of the pre / post config happens within the Ansible playbooks. I understand your frustration with the packaging approach. For a first approximation, getting the code for OpenStack/Python operations out of Pip makes sense. Ideally, we would be able to support both approaches. Red Hat would not support a pip based install, but I am sure some Centos base users would be happy with pip. We had the same general discussion around devstack. One issue that will become a problem, for users of RedHat specifically, is the fact that RedHat has no LXC container templates (at least none that are publicly available) and even if someone were to make an official RedHat container template there'd be issues with the containers being able to connect to the satellite servers as well as other potential license problems. I'd leave the issues with getting blessed RHEL LXC support to Red Hat. Making something that works for CentOS with publically available LXC containers there would be more what I expect from OSAD upstream. What about Fedora support? It seems to me that we would be far more likely to have something supportable with Fedora that could then be backported to CentOS? I've done some experimenting with a RedHat 7.1 hosts and CentOS 7 containers and things seem to work OK but I'd not say that I have really put a lot of effort into it. That said, if its something that you'd all like to work on I'd be happy to help out to make it all go. Sounds good. I'll give it a try after the Keystone Midcycle. -- Kevin Carter *From:* Adam Young ayo...@redhat.com *Sent:* Thursday, July 9, 2015 11:32 AM *To:* Kris G. Lindgren; John Dewey *Cc:* openstack-operators@lists.openstack.org *Subject:* Re: [Openstack-operators] OSAD for RHEL On 07/09/2015 02:16 AM, Kris G. Lindgren wrote: Does OSP support running each service in an LXC container as well? What about nova-cells? How does it handle people who need to carry local changes? What is the upgrade path like with OSP? So, ignoring the Hypervisor for the moment, there is no reason that the rest of the controllers can't run in separate Containers. I think a container based deployment would be fantastic. venv is not really sufficient, as the system level binaries can still conflict (MysQL and LDAP both require system libraries for Keystone, for example) From an Ansible perspective; we need to be able to share the HTTPD instance for Keystone and Apache, and getting that right will solve most of the issues deploying in a secure manner. Putting Them on separate hosts or containers should be a degenerate case, and thus be supported, too. Asking, because in Philly the general consensus, I fel,t was people want to move away from the current system level package stuff and move towards: venv's, lightweight packages, containers. The only reason that was brought up to keep packages around was to solve the non-python lib stuff and using a depsolver (yum/apt) that doesn't suck (pip). So I am pretty sure my wants are inline with what other people in the community are either already doing or moving towards. ___ Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. From: John Dewey j...@dewey.ws mailto:j...@dewey.ws Date: Wednesday, July 8, 2015 at 11:43 PM To: Kris G. Lindgren klindg...@godaddy.com mailto:klindg...@godaddy.com Cc: Adam Young ayo...@redhat.com mailto:ayo...@redhat.com, openstack-operators@lists.openstack.org mailto:openstack-operators@lists.openstack.org openstack-operators@lists.openstack.org mailto:openstack-operators@lists.openstack.org Subject: Re: [Openstack-operators] OSAD for RHEL This would not be acceptable for those running OSP. On Wednesday, July 8, 2015 at 10:12 PM, Kris G. Lindgren wrote: I should be more clear. My current thought is to have a venv packaged inside an rpm - so the rpm includes the needed init scripts, ensures the required system level binaries are installed, adds the users - ect ect. But would be a single deployable autonomous unit. Also, have a versioning schema to roll forward and back between venvs for quick update/rollback
Re: [Openstack-operators] OSAD for RHEL
On 07/07/2015 05:55 PM, Kris G. Lindgren wrote: +1 on RHEL support. I have some interest in moving away from packages and am interested in the OSAD tooling as well. I would not recommend an approach targetting RHEL that does not use packages. OSAD support for RHEL using packages would be an outstanding tool. Which way are you planning on taking it? Kris Lindgren Senior Linux Systems Engineer GoDaddy, LLC. On 7/7/15, 3:38 PM, Abel Lopez alopg...@gmail.com wrote: Hey everyone, I've started looking at osad, and I like much of the direction it takes. I'm pretty interested in developing it to run on RHEL, I just wanted to check if anyone would be -2 opposed to that before I spend cycles on it. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] [openstack-operators] Onboarding Legacy Apps into OpenStack
On 06/15/2015 07:46 PM, Barrett, Carol L wrote: Operators – The Enterprise Work Group (formerly known as Win The Enterprise) has a team working on a Proof Of Concept for using Metadata to describe requirements for legacy apps and workloads to be on boarded onto an OpenStack Cloud. We have 2 use cases that we are planning to implement: Encrypted Storage and Workload Isolation. You can find these use cases here: I am asking for your help: 1. We’re looking for an Operator who has a real world example of either of these use cases and can share information about config and overall requirements. We want to make sure our PoC is realistic. 2. We need more use cases to run through our PoC. Do you have Legacy App or Workload that you can work with us to write up a use case around? If you’re game for either of these please let me know. Thanks Carol Barrett ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators I'm not an operator, but I play one on TV. My examples are not real world except as a developer using OpenStack. I want to be able to launch a VM and have it automatically register with an Identity management service. To do this, I need to generate a one time password that gets passed to both the IdM and to the VM, and User-Data seems to be the only tool. However, I would ideally have something that perform this workflow, regardless of how the user kicked off the task, and that would not require the user to modify the user-data when launching the VM; it would be a property of the project instead. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Ops Keystone / Federation Session
On 05/23/2015 02:50 PM, Tim Bell wrote: Joe, Thanks for the notes. We had a productive discussion with the Glance folk on how to share images across clouds (https://libertydesignsummit.sched.org/event/6b4a5dbd177cde2aad7a9927a82534d0#.VWDLPpOqqko) and we’ll be working on that spec. We also had some forward looking discussions with the Keystone team on how to manage multi-cloud nested projects. As joe said, Federated identity is needed but giving users a transparent exprience will take much, much more. Are there blueprints created for this gap ? I don't think so, as they really are cross-project blueprints. I was thinking that there needs to be an owner, and the down in the big tent is something like this: Ceilometer is responsible for responding to events and kicking off workflows Mistral is responsible for defining workflows. While neither should be essential, or required, we should have a big-tent-only solution that people can use for reference. Keysteon can provide the user first seen event We need a time out for user not seen since X to archive their work We then need a Delete all resources at a later date. If a project is deliberately deleted, we need to catch and clean up those events as well. I suspect if we documented that much, we'd get most of the way home. Tim From: joe j...@topjian.net mailto:j...@topjian.net Date: Friday 22 May 2015 23:26 To: openstack-operators openstack-operators@lists.openstack.org mailto:openstack-operators@lists.openstack.org Subject: [Openstack-operators] Ops Keystone / Federation Session Hello, Better late than never, here's a summary of the Ops Keystone / Federation Session from this past Tuesday: First, I want to thank everyone from the Keystone team for attending the session -- it was very cool to have you guys on-hand to directly answer questions and give input and insight into the various items being discussed. This was the first time we had a discussion session dedicated to this topic and we could have easily spent entire sessions on each of the main items listed in the Etherpad https://etherpad.openstack.org/p/YVR-ops-federation. I think that shows there's a lot to be discussed with regard to federated clouds. The biggest discussion item to come out of the session was that a federated cloud means so much more than just Keystone. Allocating, restricting, automatic provisioning, reporting, and cleanup of any type of OpenStack-enabled resource in a federated cloud are all areas Operators are interested in learning about, but those areas are either not well defined (perhaps because what works for one federation won't work for another), are not possible to do yet, or are possible but Operators aren't sure how to implement them. I encourage operators who are interested in this area to keep the discussion going on this list by sharing your questions, concerns, and trials. As well, I hope to see this topic in future Ops meetups and tracks as a more formal way to touch base on this area. Etherpad: https://etherpad.openstack.org/p/YVR-ops-federation Thanks, Joe ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Horizon - domain-scoped token support
On 05/12/2015 05:43 AM, Olga Dodin wrote: Hi, For our OpenStack environment (Juno + Ubuntu 12.04 ) I have configured Identity service for multi-domain support(with keystone API v3 and sample v3 policy file). Using domain-scoped token with CLI (openstack) I can access users and projects belong to different domains. Horizon however can't use domain-scoped token and on cloud_admin login errors like Unable to retrieve user/project/domain list arise, I've tried to apply the patch https://review.openstack.org/#/c/148082/to support domain-scoped tokens in Horizon - checked out the Patch Set 63 code and copied the files listed in the patch description accordingly. Now when I try to login to openstack dashboard getting message in horizon_error.log: [error] /usr/local/lib/python2.7/dist-packages/pbr/version.py:25: UserWarning: Module openstack_dashboard was already imported from /usr/share/openstack-dashboard/openstack_dashboard/wsgi/../../openstack_dashboard/__init__.pyc, but /usr/lib/python2.7/dist-packages is being added to sys.path [error] import pkg_resources is that the whole error message? It seems like a path problem, possibly on how you applied the patch. Did you run python setup.py develop to get the change? Appreciate any help/advice on how to resolve this. Thanks, Olga Dodin Servers Network group, IBM RD Labs in Israel ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Dynamic Policy for Access Control
On 04/07/2015 11:36 AM, Marc Heckmann wrote: My apologies for not seeing this sooner as the topic is of great interest. My comments below inline.. On Mon, 2015-02-23 at 16:41 +, Tim Bell wrote: -Original Message- From: Adam Young [mailto:ayo...@redhat.com] Sent: 23 February 2015 16:45 To: openstack-operators@lists.openstack.org Subject: [Openstack-operators] Dynamic Policy for Access Control Admin can do everything! has been a common lament, heard for multiple summits. Its more than just a development issue. I'd like to fix that. I think we all would. I'm looking to get some Operator input on the Dynamic Policy issue. I wrote up a general overview last fall, after the Kilo summit: https://adam.younglogic.com/2014/11/dynamic-policy-in-keystone/ I agree with everything in that post. I would add the following comments: 1. I doubt this will change, but to be clear, we cannot lose the ability to create custom roles and limit the capabilities of the standard roles. For example, if I wanted to limit the ability to make images public or limit the ability to associate a floating IP. That is a baseline consideration. We are hoping to make custom roles the norm. 2. This work should not be done in vacuum. Ideally, Horizon support for assigning roles to users and editing policy should be released at the same time or not long after. I realize that this is easier said than done, but it will be important in order for the feature to get used. Role assignments will be done the same way they are now, as Horizon fetches the list of roles from Keystone. Editing policy will require a new UI. I don't see that happening in Horizon until the Keystone mechanism is finalized. Thanks for the response. We can carry on the conversation at the Summit. Some of what I am looking at is: what are the general roles that Operators would like to have by default when deploying OpenStack? As I described in http://openstack-in-production.blogspot.ch/2015/02/delegation-of-roles.html, we've got (mapped per-project to an AD group) - operator (start/stop/reboot/console) - accounting (read ceilometer data for reporting) I've submitted a talk about policy for the Summit: https://www.openstack.org/vote-vancouver/presentation/dynamic-policy-for- access-control If you want, please vote for it, but even if it does not get selected, I'd like to discuss Policy with the operators at the summit, as input to the Keystone development effort. Sounds like a good topic for the ops meetup track. Feedback greatly welcome. ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
Re: [Openstack-operators] Security around enterprise credentials and OpenStack API
On 03/31/2015 10:58 PM, Marc Heckmann wrote: Hi all, I was going to post a similar question this evening, so I decided to just bounce on Mathieu’s question. See below inline. On Mar 31, 2015, at 8:35 PM, Matt Fischer m...@mattfischer.com wrote: Mathieu, We LDAP (AD) with a fallback to MySQL. This allows us to store service accounts (like nova) and team accounts for use in Jenkins/scripts etc in MySQL. We only do Identity via LDAP and we have a forked copy of this driver (https://github.com/SUSE-Cloud/keystone-hybrid-backend) to do this. We don't have any permissions to write into LDAP or move people into groups, so we keep a copy of users locally for purposes of user-list operations. The only interaction between OpenStack and LDAP for us is when that driver tries a bind. On Tue, Mar 31, 2015 at 6:06 PM, Mathieu Gagné mga...@iweb.com wrote: Hi, Lets say I wish to use an existing enterprise LDAP service to manage my OpenStack users so I only have one place to manage users. How would you manage authentication and credentials from a security point of view? Do you tell your users to use their enterprise credentials or do you use an other method/credentials? We too have integration with enterprise credentials through LDAP, but as you suggest, we certainly don’t want users to use those credentials in scripts or store them on instances. Instead we have a custom Web portal where they can create separate Keystone credentials for their project/tenant which are stored in Keystone’s MySQL database. Our LDAP integration actually happens at a level above Keystone. We don’t actually let users acquire Keystone tokens using their LDAP accounts. We’re not really happy with this solution, it’s a hack and we are looking to revamp it entirely. The problem is that I never have been able to find a clear answer on how to do this with Keystone. I’m actually quite partial to the way AWS IAM works. Especially the instance “role features. Roles in AWS IAM is similar to TRUSTS in Keystone except that it is integrated into the instance metadata. It’s pretty cool. Other than that, RBAC policies in Openstack get us a good way towards IAM like functionality. We just need a policy editor in Horizon. Anyway, the problem is around delegation of credentials which are used non-interactively. We need to limit what those users can do (through RBAC policy) but also somehow make the credentials ephemeral. If someone (Keystone developer?) could point us in the right direction, that would be great. Kerberos. Works well for Keystone. http://adam.younglogic.com/2014/07/kerberos-for-horizon-and-keystone/ We are working on Kerberos support for Horizon as well, but we might not get it blessed by Kilo time frame. I think there might be a better approach on the Horizon front using SSSD and Federation: http://adam.younglogic.com/2015/03/key-fed-lookup-redux/ That will likely work with Horizon as is (in Kilo) but I have not yet tested it...doing so is on my short list. What CERN is doing is using SAML for everything, and using ADFS with a discovery page to let you use X509, Kerberos, or Password to get a SAML assertion, and then handing that over to Horizon. SAML against Keystone CLI wise requires ECP support on the SAML side...you've been warned,. Thanks in advance. The reason is that (usually) enterprise credentials also give access to a whole lot of systems other than OpenStack itself. And it goes without saying that I'm not fond of the idea of storing my password in plain text to be used by some scripts I created. What's your opinion/suggestion? Do you guys have a second credential system solely used for OpenStack? -- Mathieu ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators ___ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators