add permissions for jenkins

[deads2k]

Adds permissions to the admin, edit, and view roles for jenkins access as allowed by openshift/jenkins-openshift-login-plugin#2 .

@bparees @gabemontero are we trying to push this into 1.3?

[deads2k]

@openshift/api-review I intentionally chose verbs that don't match our normal resource verbs so that these permissions can never grant "normal" API access.

[smarterclayton]

builds? To match "apps" and "extensions"?

[deads2k]

builds? To match "apps" and "extensions"?

"batch" and "imagepolicy"? We've gone back and forth before in one of @mfojtik's pulls. I kind of expect that a group is a singular construct. Probably because I say, "<collective noun> is", not "<collective noun> are"

[deads2k]

builds? To match "apps" and "extensions"?
"batch" and "imagepolicy"? We've gone back and forth before in one of @mfojtik's pulls. I kind of expect that a group is a singular construct. Probably because I say, " is", not " are"

I don't feel strongly, but I do want to be consistent in openshift.

Also: authorization and authentication are singular nouns.

[smarterclayton]

Technically all of those nouns describe processes. The word to describe a build process is "building". Also "app" sounds wrong. You generally don't pluralize processes, but you do pluralize groups of things.

Is there a rule that we are using singular nouns? Or the rule is that we're describing what the group does / contains.

[smarterclayton]

So "get" and "view"? Seems a bit weird - how about "external-get" and "external-put"? I don't hate it, but I suspect people will get confused there.

[bparees]

@bparees @gabemontero are we trying to push this into 1.3?

no

[deads2k]

Technically all of those nouns describe processes. The word to describe a build process is "building". Also "app" sounds wrong. You generally don't pluralize processes, but you do pluralize groups of things.

Is there a rule that we are using singular nouns? Or the rule is that we're describing what the group does / contains.

Found the original issue: #9372 (comment), copying here:

1. authorization
2. build
3. deploy
4. image
5. oauth
6. project
7. route
8. sdn - networking?
9. template
10. user
11. security - I don't like the name. This holds SCC today.

How about we decide for real this time and I'll create a const in each one.

[bparees]

so if i get jenkins view/edit/admin permissions on a project, i'm going to have those permissions in all the jenkins servers within a project I guess?

are we ok w/ that coarse a level of granularity? (I think I am, but it seems worth making it clear)

[bparees]

So "get" and "view"? Seems a bit weird - how about "external-get" and "external-put"? I don't hate it, but I suspect people will get confused there.

it's always going to be used in conjunction w/ the "jenkins" resource, right? so "jenkins/external-get" sounds weird to me. (whereas jenkins/view or jenkins/get does not)

[smarterclayton]

I like the names being singular. All but security sounds fine, agree we need a better one for that.

[deads2k]

so if i get jenkins view/edit/admin permissions on a project, i'm going to have those permissions in all the jenkins servers within a project I guess?

are we ok w/ that coarse a level of granularity? (I think I am, but it seems worth making it clear)

I would start there. If you want to find a way to name a jenkins, you could check for access on a particular one, but it would be a considerable amount of work to subdivide the permissions. We've said the ACL boundary is project, I think I'd try to stay there.

[deads2k]

Future names added to each group.

@smarterclayton how do you feel about the verb choice? Sounds like @bparees prefers admin, edit, view.

[smarterclayton]

I think adding new verbs that are synonyms to existing verbs is risky from a confusion point of view.

[deads2k]

I think adding new verbs that are synonyms to existing verbs is risky from a confusion point of view.

Ok, we'll need three verbs to give the three levels: admin, edit, view for jenkins. I mapped them to common roles that happen to match names and be verbs, but I'm open to other mappings.

Keep in mind that if you use get for any of them, you'll have a direct impact on the authorization of "normal" resources, so you'll be claiming one of @bparees's names.

[smarterclayton]

I'm fine with admin/edit/view - david and I discussed and we could make the
argument that if you use subresource you still have to pick an arbitrary
verb (get, etc) which did not feel right. We may regret adding more verbs
later, but it's the cleanest mapping today.

On Mon, Aug 29, 2016 at 7:48 AM, David Eads notifications@github.com
wrote:

I think adding new verbs that are synonyms to existing verbs is risky from
a confusion point of view.

Ok, we'll need three verbs to give the three levels: admin, edit, view for
jenkins. I mapped them to common roles that happen to match names and be
verbs, but I'm open to other mappings.

Keep in mind that if you use get for any of them, you'll have a direct
impact on the authorization of "normal" resources, so you'll be claiming
one of @bparees https://github.com/bparees's names.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#10649 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_p6SOh9Xz-ZxwtCzAZ_00NEBpxMP3ks5qkscggaJpZM4JtaJl
.

[deads2k]

@bparees this is a safe change. You want it in 1.3?

[bparees]

@deads2k i don't think we care, so it can wait.

[deads2k]

Spoke with @bparees in irc. This is needed for 1.3 compatibility with new jenkins images. [merge]

[deads2k]

[test]

[openshift-bot]

Evaluated for origin test up to d1098eb

[openshift-bot]

continuous-integration/openshift-jenkins/test FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/8553/)

[openshift-bot]

Evaluated for origin merge up to d1098eb

[openshift-bot]

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/8555/) (Image: devenv-rhel7_4954)