<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">On 07/17/2017 10:12 PM, Lance Bragstad
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAE6oFcG=SxwoK3-N45Jm=Z17hYy8ZMR424MM1HDXAdFzhCdw4Q@mail.gmail.com">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Mon, Jul 17, 2017 at 6:39 PM, Zane
Bitter <span dir="ltr"><<a
href="mailto:zbitter@redhat.com" target="_blank"
moz-do-not-send="true">zbitter@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">So the
application credentials spec has merged - huge thanks to
Monty and the Keystone team for getting this done:<br>
<br>
<a href="https://review.openstack.org/#/c/450415/"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://review.openstack.org/#<wbr>/c/450415/</a><br>
<a
href="http://specs.openstack.org/openstack/keystone-specs/specs/keystone/pike/application-credentials.html"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://specs.openstack.org/ope<wbr>nstack/keystone-specs/specs/<wbr>keystone/pike/application-<wbr>credentials.html</a><br>
<br>
However, it appears that there was a disconnect in how two
groups of folks were reading the spec that only became
apparent towards the end of the process. Specifically, at
this exact moment:<br>
<br>
<a
href="http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-06-09.log.html#t2017-06-09T17:43:59"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://eavesdrop.openstack.org<wbr>/irclogs/%23openstack-keystone<wbr>/%23openstack-keystone.2017-<wbr>06-09.log.html#t2017-06-09T17:<wbr>43:59</a><br>
<br>
To summarise, Keystone folks are uncomfortable with the
idea of application credentials that share the lifecycle
of the project (rather than the user that created them),
because a consumer could surreptitiously create an
application credential and continue to use that to access
the OpenStack APIs even after their User account is
deleted. The agreed solution was to delete the application
credentials when the User that created them is deleted,
thus tying the lifecycle to that of the User.<br>
<br>
This means that teams using this feature will need to
audit all of their applications for credential usage and
rotate any credentials created by a soon-to-be-former team
member *before* removing said team member's User account,
or risk breakage. Basically we're relying on users to do
the Right Thing (bad), but when they don't we're
defaulting to breaking [some of] their apps over leaving
them insecure (all things being equal, good).<br>
<br>
Unfortunately, if we do regard this as a serious problem,
I don't think this solution is sufficient. Assuming that
application credentials are stored on VMs in the project
for use by the applications running on them, then anyone
with access to those servers can obtain the credentials
and continue to use them even if their own account is
deleted. The solution to this is to rotate *all*
application keys when a user is deleted. So really we're
relying on users to do the Right Thing (bad), but when
they don't we're defaulting to breaking [some of] their
apps *and* [potentially] leaving them insecure (worst
possible combination).<br>
<br>
(We're also being inconsistent, because according to the
spec if you revoke a role from a User then any application
credentials they've created that rely on that role
continue to work. It's only if you delete the User that
they're revoked.)<br>
<br>
<br>
As far as I can see, there are only two solutions to the
fundamental problem:<br>
<br>
1) Fine-grained user-defined access control. We can
minimise the set of things that the application
credentials are authorised to do. That's out of scope for
this spec, but something we're already planning as a
future enhancement.<br>
2) Automated regular rotation of credentials. We can make
sure that whatever a departing team member does manage to
hang onto quickly becomes useless.<br>
<br>
By way of comparison, AWS does both. There's fine-grained
defined access control in the form of IAM Roles, and these
Roles can be associated with EC2 servers. The servers have
an account with rotating keys provided through the
metadata server. I can't find the exact period of rotation
documented, but it's on the order of magnitude of 1 hour.<br>
<br>
There's plenty not to like about this design.
Specifically, it's 2017 not 2007 and the idea that there's
no point offering to segment permissions at a finer
grained level than that of a VM no longer holds water
IMHO, thanks to SELinux and containers. It'd be nice to be
able to provide multiple sets of credentials to different
services running on a VM, and it's probably essential to
our survival that we find a way to provide individual
credentials to containers. Nevertheless, what they have
does solve the problem.<br>
<br>
Note that there's pretty much no sane way for the user to
automate credential rotation themselves, because it's
turtles all the way down. e.g. it's easy in principle to
set up a Heat template with a Mistral workflow that will
rotate the credentials for you, but they'll do so using
trusts that are, in turn, tied back to the consumer who
created the stack. (It suddenly occurs to me that this is
a problem that all services using trusts are going to need
to solve.) Somewhere it all has to be tied back to
something that survives the entire lifecycle of the
project.<br>
<br>
Would Keystone folks be happy to allow persistent
credentials once we have a way to hand out only the
minimum required privileges?<br>
</blockquote>
<div><br>
</div>
<div>If I'm understanding correctly, this would make
application credentials dependent on several cycles of
policy work. Right?</div>
</div>
</div>
</div>
</blockquote>
<br>
I think having the ability to communicate deprecations though
oslo.policy would help here. We could use it to move towards better
default roles, which requires being able to set minimum privileges.
<br>
<br>
Using the current workflow requires operators to define the minimum
privileges for whatever is using the application credential, and
work that into their policy. Is that the intended workflow that we
want to put on the users and operators of application credentials?<br>
<br>
<blockquote type="cite"
cite="mid:CAE6oFcG=SxwoK3-N45Jm=Z17hYy8ZMR424MM1HDXAdFzhCdw4Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If not I think we're back to <a
href="https://review.openstack.org/#/c/222293/"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://review.openstack.org/#<wbr>/c/222293/</a><br>
<br>
cheers,<br>
Zane.<br>
<br>
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage
questions)<br>
Unsubscribe: <a
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
rel="noreferrer" target="_blank" moz-do-not-send="true">OpenStack-dev-request@lists.op<wbr>enstack.org?subject:unsubscrib<wbr>e</a><br>
<a
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-dev</a><br>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</body>
</html>