User with privileged SCC can't let images start as default user

[smarterclayton]

Pod created by cluster-admin is getting UID (first in range from project) assigned, but should have no uid set (because RunAsAny).

[smarterclayton]

I1022 05:08:19.208508    6230 admission.go:110] getting security context constraints for pod hello-openshift (generate: ) in namespace default with user info &{system:admin  [system:cluster-admins system:authenticated]}
I1022 05:08:19.209151    6230 admission.go:119] getting security context constraints for pod hello-openshift (generate: ) with service account info &{system:serviceaccount:default:default  [system:serviceaccounts system:serviceaccounts:default]}
I1022 05:08:19.211671    6230 admission.go:335] got preallocated values for min: 1000010000, max: 1000019999 for uid range in namespace default
I1022 05:08:19.211722    6230 admission.go:348] got preallocated value for level: s0:c3,c2 for selinux options in namespace default
I1022 05:08:19.212470    6230 admission.go:393] validating pod hello-openshift (generate: ) against providers restricted,privileged
I1022 05:08:19.212881    6230 admission.go:146] pod hello-openshift (generate: ) validated against provider restricted

[smarterclayton]

oc create -f examples/hello-openshift/hello-pod.json

from the default namespace

[pweil-]

Unless you specifically ask for something you will run as the most restrictive context available to you. In this case the admin has access to both the restricted and privileged scc. You should be able to set the RunAsUser to anything you want though.

[pweil-]

proposal:

Requirements

1. Allow users to use their least restrictive SCC by default when creating pods rather than having to request elevated privileges to activate a less restrictive SCC
2. Allow administrators to influence the order in which SCC generation/validation is attempted per namespace

Changes

1. Refactor the existing ByRestrictions sorter to reverse the order that SCCs are sorted.
2. Introduce a new, per-namespace annotation of `sa.scc.sort="comma, delim, list, of, scc, names"
3. Adapt the sorter to provide increased scoring for SCCs named in the namespace annotation
4. Current scoring adds weighted points per escalated feature. The less restricted an SCC is, the higher the score
5. For SCCs in the namespace annotation point scoring is overridden such that anything in the annotation is given a score of 500 - idx where idx is the SCC's position in the annotation.

Use cases

Assumptions

Current scoring mechanism is modified for new features being introduced and will look as follows:

1. priv = 100
2. host dir = 10
3. host pid = 10
4. host ipc = 10
5. host network = 10
6. host ports = 10
7. RunAsAny strat = 4
8. RunAsNonRoot strat = 3
9. RunAsRangeStrat = 2
10. MustRunAsStrat = 1

Max base score for everything except root (4 strategies): 66
Min base score: 4

All use cases assume the following SCCs are configured:

1. privileged: base score of 166 (priv + all host access + all RunAsAny strats)
2. semi-privileged: base score of 66 (all host access + RunAsAny strats)
3. restricted: base score of 4

Use cases describe the returned sort in the form of [name:score]

No ns annotation

1. Granted access to restricted only returns sort of [restricted:4]
2. Granted access to restricted and semi-privileged returns sort of [semi-privileged:66, restricted:4]
3. Granted access to all SCCs returns sort of [privileged:166, semi-privileged:66, restricted:4]

NS annotation of 'restricted'

1. Granted access to restricted only returns sort of [restricted:500]
2. Granted access to restricted and semi-privileged returns sort of [restricted:500, semi-privileged:66]
3. Granted access to all SCCs returns sort of [restricted:500, privileged: 166, semi-privileged:66]

NS annotation of 'restricted,semi-privileged'

1. Granted access to restricted only returns sort of [restricted:500]
2. Granted access to restricted and semi-privileged returns sort of [restricted:500, semi-privileged:499]
3. Granted access to all SCCs returns sort of [restricted:500, semi-privileged:499, privileged: 166]

NS annotation of 'restricted,semi-privileged,privileged'

1. Granted access to restricted only returns sort of [restricted:500]
2. Granted access to restricted and semi-privileged returns sort of [restricted:500, semi-privileged:499]
3. Granted access to all SCCs returns sort of [restricted:500, semi-privileged:499, privileged: 498]

NS annotation of 'semi-privileged,restricted,privileged'

1. Granted access to restricted only returns sort of [restricted:499]
2. Granted access to restricted and semi-privileged returns sort of [semi-privileged:500, restricted:499]
3. Granted access to all SCCs returns sort of [semi-privileged:500, restricted:499, privileged:498]

[smarterclayton]

I would rephrase the requirements:

1. If a SCC allows a default to be applied to be used from the image, use
   that in preference to the most restrictive
   a. This applies for all allocated fields from the namespace

Why can we not structured this as "if the allowed SCCs allows the pod to
use an inherited default for a known set of inherited defaults, don't
enforce".

On Mon, Oct 26, 2015 at 5:14 PM, Paul Weil [email protected] wrote:

proposal:
Requirements

1. Allow users to use their least restrictive SCC by default when
   creating pods rather than having to request elevated privileges to activate
   a less restrictive SCC
2. Allow administrators to influence the order in which SCC
   generation/validation is attempted per namespace

Changes

1. Refactor the existing ByRestrictions sorter to reverse the order
   that SCCs are sorted.
2. Introduce a new, per-namespace annotation of `sa.scc.sort="comma,
   delim, list, of, scc, names"
3. Adapt the sorter to provide increased scoring for SCCs named in the
   namespace annotation
   1. Current scoring adds weighted points per escalated feature. The
      less restricted an SCC is, the higher the score
   2. For SCCs in the namespace annotation point scoring is overridden
      such that anything in the annotation is given a score of 500 - idx) where
      idx is the SCC's position in the annotation.

Use cases Assumptions

Current scoring mechanism is modified for new features being introduced
and will look as follows:

1. priv = 100
2. host dir = 10
3. host pid = 10
4. host ipc = 10
5. host network = 10
6. host ports = 10
7. RunAsAny strat = 4
8. RunAsNonRoot strat = 3
9. RunAsRangeStrat = 2
10. MustRunAsStrat = 1

Max base score for everything except root (4 strategies): 66
Min base score: 4

All use cases assume the following SCCs are configured:

1. privileged: base score of 166 (priv + all host access + all
   RunAsAny strats)
2. semi-privileged: base score of 66 (all host access + RunAsAny
   strats)
3. restricted: base score of 4

Use cases describe the returned sort in the form of [name:score]
No ns annotation

1. Granted access to restricted only returns sort of [restricted:4]
2. Granted access to restricted and semi-privileged returns sort of
   [semi-privileged:66, restricted:4]
3. Granted access to all SCCs returns sort of [privileged:166,
   semi-privileged:66, restricted:4]

NS annotation of 'restricted'

1. Granted access to restricted only returns sort of [restricted:500]
2. Granted access to restricted and semi-privileged returns sort of
   [restricted:500, semi-privileged:66]
3. Granted access to all SCCs returns sort of [restricted:500,
   privileged: 166, semi-privileged:66]

NS annotation of 'restricted,semi-privileged'

1. Granted access to restricted only returns sort of [restricted:500]
2. Granted access to restricted and semi-privileged returns sort of
   [restricted:500, semi-privileged:499]
3. Granted access to all SCCs returns sort of [restricted:500,
   semi-privileged:499, privileged: 166]

NS annotation of 'restricted,semi-privileged,privileged'

1. Granted access to restricted only returns sort of [restricted:500]
2. Granted access to restricted and semi-privileged returns sort of
   [restricted:500, semi-privileged:499]
3. Granted access to all SCCs returns sort of [restricted:500,
   semi-privileged:499, privileged: 498]

NS annotation of 'semi-privileged,restricted,privileged'

1. Granted access to restricted only returns sort of [restricted:499]
2. Granted access to restricted and semi-privileged returns sort of []
3. Granted access to all SCCs returns sort of [semi-privileged:500,
   restricted:499, privileged:498]

—
Reply to this email directly or view it on GitHub
#5317 (comment).

[liggitt]

Yeah, it's more "select the SCC that requires the least mutation of the pod"

[pweil-]

Do we not get that by default if we reverse the points comparison? Strategies that allow using dockerfile defaults are RunAsAny and RunAsNonRoot which have higher scores.

[liggitt]

"security points" isn't the same as "mutation distance"... only the RunAs strategies mutate (I think)

[pweil-]

That's correct. In that case we would only need to rate mutating strategies so the sort code could be reduced quite a bit. Ok with the admin influence piece of this?

[liggitt]

Ok with the admin influence piece of this?

I guess

[smarterclayton]

The question is do we even need this complexity. The use case for keeping
admin influence and sorting is "let the admin impose a default". But I
think that's better targeted by something like "apply this SCC as the
defaults to the pod if the user has access to it." Can't we just break
this up into

1. Apply defaults
2. Verify access

On Tue, Oct 27, 2015 at 9:41 AM, Jordan Liggitt [email protected]
wrote:

Ok with the admin influence piece of this?

I guess

—
Reply to this email directly or view it on GitHub
#5317 (comment).

[pweil-]

ok. In that case, how about if the annotation takes only takes a single, named SCC for the namespace. If it exists it is bumped to the front of the line, period. No changing of scores, no changing of sort methods.

So the behavior would be:

1. secure by default, you generate/validate against the most restrictive scc that supports the request
2. UNLESS your namespace has a preferred SCC in which case you'll generate/validate against the provided SCC first and fall back to item 1

[smarterclayton]

Jordan and I argued for a bit. Here's the proposal:

1. Add a priority field to SCC which is "defaultingOrder" or
   "defaultingPriority"
2. Create a few new SCCs between restricted and privileged - one being
   "runAsAny" (or a better name, like "relaxed")
3. Find the SCCs that apply, sort them by priority only, apply a
   deterministic sort when priorities are equal (name), drop all existing
   magic sorting rules), apply those as defaults. Defaulting only sets unset
   fields
4. Validate the final result against their SCCs that apply

On Tue, Oct 27, 2015 at 11:07 AM, Paul Weil [email protected]
wrote:

ok. In that case, how about if the annotation takes only takes a single,
named SCC for the namespace. If it exists it is bumped to the front of the
line, period. No changing of scores, no changing of sort methods.

So the behavior would be:

1. secure by default, you generate/validate against the most
   restrictive scc that supports the request
2. UNLESS your namespace has a preferred SCC in which case you'll
   generate/validate against the provided SCC first and fall back to item 1

—
Reply to this email directly or view it on GitHub
#5317 (comment).

[smarterclayton]

Basically this replaces the calculated sorting (most-least restrictive,
somewhat arbitrary) with admin controlled ordering.

On Tue, Oct 27, 2015 at 11:33 AM, Clayton Coleman [email protected]
wrote:

Jordan and I argued for a bit. Here's the proposal:

1. Add a priority field to SCC which is "defaultingOrder" or
   "defaultingPriority"
2. Create a few new SCCs between restricted and privileged - one being
   "runAsAny" (or a better name, like "relaxed")
3. Find the SCCs that apply, sort them by priority only, apply a
   deterministic sort when priorities are equal (name), drop all existing
   magic sorting rules), apply those as defaults. Defaulting only sets unset
   fields
4. Validate the final result against their SCCs that apply

On Tue, Oct 27, 2015 at 11:07 AM, Paul Weil [email protected]
wrote:

ok. In that case, how about if the annotation takes only takes a single,
named SCC for the namespace. If it exists it is bumped to the front of the
line, period. No changing of scores, no changing of sort methods.

So the behavior would be:

1. secure by default, you generate/validate against the most
   restrictive scc that supports the request
2. UNLESS your namespace has a preferred SCC in which case you'll
   generate/validate against the provided SCC first and fall back to item 1

—
Reply to this email directly or view it on GitHub
#5317 (comment).

[liggitt]

3 - Find the SCCs that apply, sort them by priority only, apply a deterministic sort when priorities are equal (name), drop all existing magic sorting rules), apply those as defaults. Defaulting only sets unset fields
4 - Validate the final result against their SCCs that apply

Close, but I think you only need step 3, and the application of an SCC should stay the same as it is today. Only the way we select the SCC would change. Some constraints (RunAsAny) wouldn't mutate the pod, while others would (RunAsRange). Which SCC gets selected determines whether the pod is mutated

[pweil-]

@liggitt - got it. Discussed in IRC. This won't change the way admission behaves (only the ByRestrictions sorter which will no longer be by restrictions it will be by priority) so I think it is relatively minor. I'll work it up.