Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow setting volumes:["none"] to disallow all volume types in SCC #14625

Merged
merged 2 commits into from
Jun 16, 2017
Merged

Allow setting volumes:["none"] to disallow all volume types in SCC #14625

merged 2 commits into from
Jun 16, 2017

Conversation

liggitt
Copy link
Contributor

@liggitt liggitt commented Jun 14, 2017

xref #13419

When reading old SCC objects, we default volumes: null to mean volumes: [*] for backwards compatibility.

If you wanted to disallow all volumes, previously you would specify volumes: []. Once we switch to storing in protobuf, [] will no longer be stored, which means we would default back to [*] the next time we read the object from etcd.

Given that an SCC that disallows all volumes is not usable (since all pods have a secret volume), my main concern is ensuring a previously useless SCC stored in etcd doesn't suddenly become a very permissive SCC.

This PR:

  • defaults an SCC with volumes: [] to volumes: [none] (so it can be persisted regardless of storage type and not escalate to allow all volumes on next read)
  • validates that an SCC that specifies volumes: [none] doesn't allow any other volume types

@liggitt
Copy link
Contributor Author

liggitt commented Jun 14, 2017

[test]

@liggitt
Copy link
Contributor Author

liggitt commented Jun 14, 2017

cc @openshift/api-review @ironcladlou @smarterclayton

@deads2k
Copy link
Contributor

deads2k commented Jun 14, 2017

looks reasonable to me

@smarterclayton
Copy link
Contributor

smarterclayton commented Jun 14, 2017

LGTM, API changes are ok (i briefly contemplated None but if anyone adds a formal none volume type I'll shoot them).

@smarterclayton
Copy link
Contributor

smarterclayton commented Jun 14, 2017 via email

@openshift-bot
Copy link
Contributor

openshift-bot commented Jun 14, 2017

continuous-integration/openshift-jenkins/merge Waiting: You are in the build queue at position: 5

@openshift-bot
Copy link
Contributor

Evaluated for origin merge up to 4b85a5a

@liggitt
Copy link
Contributor Author

liggitt commented Jun 14, 2017

forgot I have to regenerate API docs, will update. hope I make it before I reach the head of the merge queue

@liggitt
Copy link
Contributor Author

liggitt commented Jun 14, 2017

this is the reason we want to run oadm migrate storage prior to an etcd v3 upgrade

etcd v3 upgrade doesn't do json -> proto, does it? the next time the json is read from etcd v3, this would do the conversion properly

@smarterclayton
Copy link
Contributor

smarterclayton commented Jun 14, 2017 via email

@liggitt
Copy link
Contributor Author

liggitt commented Jun 14, 2017

actually, an old API server fed volumes: ["none"] would also disallow all volume types, which is unexpectedly compatible

@liggitt
Copy link
Contributor Author

liggitt commented Jun 14, 2017

hmm... concerning that jenkins was green (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin/2225/) when my UPSTREAM commit didn't pass the upstream commit checker (https://travis-ci.org/openshift/origin/builds/242888676)

@stevekuznetsov, are we not running that in jenkins?

@smarterclayton
Copy link
Contributor

smarterclayton commented Jun 14, 2017 via email

@liggitt
Copy link
Contributor Author

liggitt commented Jun 14, 2017

does red travis block merge?

@smarterclayton
Copy link
Contributor

smarterclayton commented Jun 14, 2017 via email

@liggitt liggitt modified the milestone: 3.6.0 Jun 14, 2017
@stevekuznetsov
Copy link
Contributor

We definitely do run that in the check job -- before we jump into hack/env and run the tests:

+ RESTORE_AND_VERIFY_GODEPS=1
+ make verify-commits -j
hack/verify-upstream-commits.sh
[WARNING] No compiled `commitchecker` binary was found. Attempting to build one using:
[WARNING]   $ hack/build-go.sh tools/rebasehelpers/commitchecker
++ Building go targets for linux/amd64: tools/rebasehelpers/commitchecker
/data/src/github.com/openshift/origin/hack/build-go.sh took 14 seconds
===== Verifying UPSTREAM Commits =====
SUCCESS: All commits are valid.

Is that checker broken?

@liggitt
Copy link
Contributor Author

liggitt commented Jun 14, 2017

Is that checker broken?

It turned Travis red, so I don't think so

@stevekuznetsov
Copy link
Contributor

Once we've got the right git state we run:

# run commitchecker outside release container as it needs
# access to git; also explicitly force godeps verification
branch="$( git rev-parse --abbrev-ref --symbolic-full-name HEAD )"
if [[ "${branch}" == "master" ]]; then
  RESTORE_AND_VERIFY_GODEPS=1 make verify-commits -j
fi

OS_BUILD_ENV_PRESERVE=_output/scripts hack/env TEST_KUBE='true' JUNIT_REPORT='true' make check -j -k

@stevekuznetsov
Copy link
Contributor

@liggitt do you have a git reflog to show us the history of this branch? It looks like Travis recorded the commit it merged as 2db9358 and our Jenkins CI says 793f7b1

@stevekuznetsov
Copy link
Contributor

Nevermind... Travis was pointing at the merge commit but nevertheless had 793f7b1

We should probably create logging for commitchecker so we can debug post-facto

@stevekuznetsov
Copy link
Contributor

@liggitt would appreciate it if you could push that bad ref up as a new PR for repro

@smarterclayton
Copy link
Contributor

[test]

}
if hasNone {
allErrs = append(allErrs, field.Invalid(field.NewPath("volumes"), scc.Volumes,
"if 'none' is specified, no other values are allowed"))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you inline this to the if, it will be possible to use field.Index() to complain on particular element.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need a test for that?

if len(scc.Volumes) > 1 {
hasNone := false
for _, fsType := range scc.Volumes {
if fsType == api.FSTypeNone {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible that user specify 'None' or 'NONE'? Would it work?

@php-coder
Copy link
Contributor

Does Kubernetes has the same issue? Are they going to do the same?

@liggitt
Copy link
Contributor Author

liggitt commented Jun 15, 2017

Does Kubernetes has the same issue? Are they going to do the same?

They do not, because the first version of PSP had the Volumes field, so they don't have to default nil to mean "allow all"


default:
// defaults the volume slice of the SCC.
// In order to support old clients the boolean fields will always take precedence.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In order to support old clients the boolean fields will always take precedence.

About what "boolean fields" this comment is talking? Does it mean AllowHostDirVolumePlugin?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes

@php-coder
Copy link
Contributor

It would be good to also ignore this new value when we're comparing SCCs to sort them by priority:

case kapi.FSTypeSecret, kapi.FSTypeConfigMap,
kapi.FSTypeEmptyDir, kapi.FSTypeDownwardAPI:

@liggitt
Copy link
Contributor Author

liggitt commented Jun 15, 2017

updated byrestrictions, will hold for move of scc types to origin package

@deads2k
Copy link
Contributor

deads2k commented Jun 16, 2017

Chances of my pull testing green today are low. Go ahead and merege, but remind me that I need to mess with this.

@liggitt
Copy link
Contributor Author

liggitt commented Jun 16, 2017

[merge][severity:blocker]

@smarterclayton
Copy link
Contributor

[test]

1 similar comment
@smarterclayton
Copy link
Contributor

[test]

@openshift-bot
Copy link
Contributor

Evaluated for origin test up to 2136bfc

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin/2335/) (Base Commit: ee67917) (PR Branch Commit: 2136bfc)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants