Support trust id as a scope in the OpenStack authentication logic #32111
Conversation
|
Can a kubernetes member verify that this patch is reasonable to test? If so, please reply "ok to test". Regular contributors should join the org to skip this step. |
k8s-github-robot
added
size/S
|
Please not merge for the moment : the CLA is with my old employer, I am working on signing a new one here. I would still appreciate comments however :) |
|
can you split out the godep/vendor changes into their own commit (with a title of |
MatMaul
force-pushed
the
openstack-trustid
branch
from
00b3bf5
to
8224044
Compare
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed, please reply here (e.g.
|
|
Thanks for the answer, done. And I managed to remove the previous CLA, let's wait for the new one. |
| @@ -106,6 +108,7 @@ type Config struct { | |||
| ApiKey string `gcfg:"api-key"` | |||
| TenantId string `gcfg:"tenant-id"` | |||
| TenantName string `gcfg:"tenant-name"` | |||
| TrustId string `gcfg:"trust-id"` | |||
There was a problem hiding this comment.
don't we also need to populate AuthOptions.TokenID if you want to use passwordless TrustId? Just looking through AuthenticateV3Trust/trustv3auth in the godeps
There was a problem hiding this comment.
Actually using a token here would defeat the main use case of trusts : if we just want to delegate rights for a small time window passing a token would be enough. However in the OpenStack driver use case Kubernetes is a long living service and its lifetime is way higher than the token lifetime (usually a day). In this case the trust feature allows to delegate user rights to another user, that would have been created specifically for the Kubernetes cluster. Hence we do not leak the user credentials, only the creds of the user specifically created, which we don't care. And we can specify the lifetime we want for the trust when creating it (can be unlimited).
There was a problem hiding this comment.
Regarding the code, indeed it is using a first token to get a new token scoped with the trust delegation, but this first token is automatically created from the full creds if specified.
There was a problem hiding this comment.
this first token is automatically created from the full creds if specified
if the token is not specified and the username/password is? just making sure I'm understanding
There was a problem hiding this comment.
so how does this "avoid passing the user credentials in clear inside the config file"? it looks like we still have to have those
There was a problem hiding this comment.
you need to create a specific Kubernetes user, you will leak the specific user creds but we don't care since it was created for this on purpose, and you can revoke the trust delegation between the specific user and yourself whenever you want : in this case the specific user become powerless.
http://blogs.rdoproject.org/5858/role-delegation-in-keystone-trusts
liggitt
added
release-note
|
LGTM |
|
is this a dupe of #26037? |
|
LGTM, thanks! |
|
Fixes #25862, fwiw. |
|
@liggitt Is it possible to add this in 1.4? |
|
1.4 is limited to blocking bug fixes at this point, so it'll go in for 1.5 as soon as master opens back up |
MatMaul
force-pushed
the
openstack-trustid
branch
from
8224044
to
c9a05c1
Compare
|
CLAs look good, thanks! |
|
Juste rebase on top of master, and the CLA is good now :) |
|
I fixed the licenses however I don't understand the failure regarding the symbols (seems unrelated to my changes), let's see if the rebase helps. |
|
ok so if I includes the test file I get a problem with verify-symbols, and if I don't I get a problem with verify-godeps, help appreciated here :) |
|
I just understood why. |
k8s-github-robot
added
the
needs-rebase
MatMaul
force-pushed
the
openstack-trustid
branch
from
09a721d
to
ce9be8f
Compare
|
Jenkins GCI GCE e2e failed for commit ce9be8f7eb5d6500133372c8611ebfd4737625a1. Full PR test history. The magic incantation to run this job again is |
|
Jenkins Kubemark GCE e2e failed for commit ce9be8f7eb5d6500133372c8611ebfd4737625a1. Full PR test history. The magic incantation to run this job again is |
|
Jenkins unit/integration failed for commit ce9be8f7eb5d6500133372c8611ebfd4737625a1. Full PR test history. The magic incantation to run this job again is |
k8s-github-robot
removed
the
needs-rebase
|
Jenkins GCE e2e failed for commit ce9be8f7eb5d6500133372c8611ebfd4737625a1. Full PR test history. The magic incantation to run this job again is |
|
Jenkins GCE Node e2e failed for commit ce9be8f7eb5d6500133372c8611ebfd4737625a1. Full PR test history. The magic incantation to run this job again is |
MatMaul
force-pushed
the
openstack-trustid
branch
2 times, most recently
from
dda70a5
to
21d3422
Compare
|
Jenkins GKE smoke e2e failed for commit 21d3422d420e41efc6c54970ea83e7f0d4414c9a. Full PR test history. The magic incantation to run this job again is |
MatMaul
force-pushed
the
openstack-trustid
branch
from
21d3422
to
a360af2
Compare
|
Jenkins verification failed for commit a360af2b8db760dea98277f4b0b4a440fca8a620. Full PR test history. The magic incantation to run this job again is |
MatMaul
force-pushed
the
openstack-trustid
branch
from
a360af2
to
77969cd
Compare
MatMaul
force-pushed
the
openstack-trustid
branch
from
77969cd
to
c1b3100
Compare
|
The fix has been committed upstream, tests are now green ! @liggitt if you can put your LGTM again. Thanks all ! |
liggitt
added
the
lgtm
|
LGTM |
|
@k8s-bot test this [submit-queue is verifying that this PR is safe to merge] |
|
Automatic merge from submit-queue |
Automatic merge from submit-queue Support trust id as a scope in the OpenStack authentication logic This patch allows the use of Kubernetes with Keystone trust delegation to avoid passing the user credentials in clear inside the config file : a specific user with delegated rights can be created and used instead.
This patch allows the use of Kubernetes with Keystone trust delegation to avoid passing the user credentials in clear inside the config file : a specific user with delegated rights can be created and used instead.
This change is