Merge "Spec for trust"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
1ca88c35f2
|
|
@ -0,0 +1,185 @@
|
|||
==================================
|
||||
Create a trustee user for each bay
|
||||
==================================
|
||||
|
||||
https://blueprints.launchpad.net/magnum/+spec/create-trustee-user-for-each-bay
|
||||
|
||||
Some services which are running in a bay need to access OpenStack services.
|
||||
For example, Kubernetes load balancer [1] needs to access Neutron. Docker
|
||||
registry [2] needs to access Swift. In order to access OpenStack services,
|
||||
we can create a trustee for each bay and delegate a limited set of rights to
|
||||
the trustee. [3] and [4] give a brief introduction to Keystone's trusts
|
||||
mechanism.
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
Some services which are running in a bay need to access OpenStack services,
|
||||
so we need to pass user credentials into the vms.
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
|
||||
1. Kubernetes load balancer needs to access Neutron [1].
|
||||
2. For persistent storage, Cloud Provider needs to access Cinder to
|
||||
mount/unmount block storage to the node as volume [5].
|
||||
3. TLS cert is generated in the vms and need to be uploaded to Magnum [6][7].
|
||||
4. Docker registry needs to access Swift [2].
|
||||
|
||||
Project Priority
|
||||
----------------
|
||||
|
||||
High
|
||||
|
||||
Proposed change
|
||||
===============
|
||||
When a user (the "trustor") wants to create a bay, steps for trust are as
|
||||
follows.
|
||||
|
||||
1. Create a new service account (the "trustee") without any role in a domain
|
||||
which is dedicated for trust. Without any role, the service account can do
|
||||
nothing in Openstack.
|
||||
|
||||
2. Define a trust relationship between the trustor and the trustee. The trustor
|
||||
can delegate a limited set of roles to the trustee. We can add an option
|
||||
named trust_roles in baymodel. Users can add roles which they want to
|
||||
delegate into trust_roles. If trust_roles is not provided, we delegate all
|
||||
the roles to the trustee.
|
||||
|
||||
3. Services in the bay can access OpenStack services with the trustee
|
||||
credentials and the trust.
|
||||
|
||||
The roles which are delegated to the trustee should be limited. If the services
|
||||
in the bay only need access to Neutron, we should not allow the services to
|
||||
access to other OpenStack services. But there is a limitation that a trustor
|
||||
must have the role which is delegated to a trustee [4].
|
||||
|
||||
Magnum now only allows the user who create the bay to get the certificate to
|
||||
avoid the security risk introduced by Docker [8]. For example, if other users
|
||||
in the same tenant can get the certificate, then they can use Docker API to
|
||||
access the host file system of a bay node and get anything they want::
|
||||
|
||||
docker run --rm -v /:/hostroot ubuntu /bin/bash \
|
||||
-c "cat /hostroot/etc/passwd"
|
||||
|
||||
If Keystone doesn't allow to create new serivce accounts when LDAP is used as
|
||||
the backend for Keystone, we can use a pre-create service account for all
|
||||
bays. In this situation, all the bays use the same service account and
|
||||
different trust. We should add an config option to choose this method.
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
Magnum can create a user for each bay with roles to access OpenStack Services
|
||||
in a dedicated domain. The method has one disadvantage. The user which is
|
||||
created by magnum may get the access to OpenStack services which this user can
|
||||
not access before. For example, a user can not access Swift service and create
|
||||
a bay. Then Magnum create a service account for this bay with roles to access
|
||||
Swift. If the user logins into the vms and get the credentials, the user can
|
||||
use these credentials to access Swift.
|
||||
|
||||
Or Magnum doesn't prepare credentials and the user who create a bay needs to
|
||||
login into the nodes to manully add credentials in config files for services.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
Trustee id, trustee password and trust id are added to Bay table in Magnum
|
||||
database.
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
Only the user who create a bay can get the certificate of this bay. Other
|
||||
users in the same tenant can not get the certificate now.
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
Trustee id and trustee password are encrypted in magnum database. When Magnum
|
||||
passes these parameters to heat to create a stack, the transmission is
|
||||
encrypted by tls, so we don't need to encrypt these credentials. These
|
||||
credentials are hidden in heat, users can not query them in stack parameters.
|
||||
|
||||
Trustee id, trustee password and trust id can be obtained in the vms. Anyone
|
||||
who can login into the vms can get them and use these credentials to access
|
||||
OpenStack services. In a production environment, these vms must be secured
|
||||
properly to prevent unauthorized access.
|
||||
|
||||
Only the user who create the bay can get the certificate to access the COE
|
||||
api, so it is not a security risk even if the COE api is not safe.
|
||||
|
||||
Notifications impact
|
||||
--------------------
|
||||
|
||||
None
|
||||
|
||||
Other end user impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Performance impact
|
||||
------------------
|
||||
|
||||
None
|
||||
|
||||
Other deployer impact
|
||||
---------------------
|
||||
|
||||
None
|
||||
|
||||
Developer impact
|
||||
----------------
|
||||
|
||||
None
|
||||
|
||||
Implementation
|
||||
==============
|
||||
|
||||
Assignee(s)
|
||||
-----------
|
||||
|
||||
Primary assignee:
|
||||
humble00 (wanghua.humble@gmail.com)
|
||||
Other contributors:
|
||||
None
|
||||
|
||||
Work Items
|
||||
----------
|
||||
|
||||
1. Create an trustee for each bay.
|
||||
2. Change the policy so that only the user who create a bay can get the
|
||||
certificate of the bay.
|
||||
|
||||
Dependencies
|
||||
============
|
||||
|
||||
None
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
Unit test and functional test for service accounts and the policy change.
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
The user guide and troubleshooting guide will be updated with details
|
||||
regarding the service accounts.
|
||||
|
||||
References
|
||||
==========
|
||||
[1] http://docs.openstack.org/developer/magnum/dev/dev-kubernetes-load-balancer.html
|
||||
[2] https://blueprints.launchpad.net/magnum/+spec/registryv2-in-master
|
||||
[3] http://blogs.rdoproject.org/5858/role-delegation-in-keystone-trusts
|
||||
[4] https://wiki.openstack.org/wiki/Keystone/Trusts
|
||||
[5] https://github.com/kubernetes/kubernetes/blob/release-1.1/examples/mysql-cinder-pd/README.md
|
||||
[6] https://bugs.launchpad.net/magnum/+bug/1503863
|
||||
[7] https://review.openstack.org/#/c/232152/
|
||||
[8] https://docs.docker.com/engine/articles/security/#docker-daemon-attack-surface
|
||||
|
||||
History
|
||||
=======
|
||||
|
||||
None
|
||||
Loading…
Reference in New Issue