Re: [Openstack-operators] [Glance] Default policy in policy.json

[Adam Young]

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

[Adam Young]

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

[Adam Young]

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

[Adam Young]

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 Holler  wrote:

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

[Adam Young]

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

[Adam Young]

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 Dewey 
100% 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

[Adam Young]

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

[Adam Young]

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

[Adam Young]

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

[Adam Young]

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

[Adam Young]

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

[Adam Young]

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

[Adam Young]

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

[Adam Young]

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

[Adam Young]

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