AllowPrivilegeEscalation aka no_new_privs

[jessfraz]

Feature Description

• One-line feature description (can be used as a release note): AllowPrivilegeEscalation when false will ensure execve promises not to grant more privileges that the parent process.
• Primary contact (assignee): @jessfraz
• Responsible SIGs: sig-auth?
• Design proposal link (community repo): https://github.com/kubernetes/community/pull/639/files
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @smarterclayton @timstclair
• Approver (likely from SIG/area to which feature belongs): @smarterclayton
• Feature target (which target equals to which milestone): 1.8
  • Alpha release target (x.y)
  • Beta release target (x.y)
  • Stable release target (x.y): 1.8

[jdumars]

/sig auth

[idvoretskyi]

@jessfraz can you define the feature roadmap more precisely (under the "Feature target" section)?
Which release equals which stage?

Thanks.

[jessfraz]

Updated, since it was added to securityContext which is stable it will be stable

[idvoretskyi]

@jessfraz thank you!

[tallclair]

since it was added to securityContext which is stable it will be stable

Not necessarily, we can add alpha fields to stable APIs now: kubernetes/community#869

Not saying it needs to be alpha, but it should be stable based on merits other than the parent API.

[jessfraz]

Oh ok, well crap did I do it wrong?

…

On Thu, Aug 3, 2017 at 1:36 PM, Tim Allclair (St. Clair) < ***@***.***> wrote: since it was added to securityContext which is stable it will be stable Not necessarily, we can add alpha fields to stable APIs now: kubernetes/community#869 <kubernetes/community#869> Not saying it needs to be alpha, but it should be stable based on merits other than the parent API. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#381 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABYNbHwiIgaoqGyybw7-OvEuJphuog2Gks5sUgUrgaJpZM4OqTDw> .

-- Jessie Frazelle 4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3 pgp.mit.edu <http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3>

[tallclair]

Since the default doesn't change anything (IIRC) and this is a relatively small feature, I'm comfortable going straight to stable. I think the main thing to pay attention to is that that requires more thorough testing and documentation.

[jessfraz]

Got it.

…

On Thu, Aug 3, 2017 at 2:25 PM, Tim Allclair (St. Clair) < ***@***.***> wrote: Since the default doesn't change anything (IIRC) and this is a relatively small feature, I'm comfortable going straight to stable. I think the main thing to pay attention to is that that requires more thorough testing and documentation. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#381 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABYNbPADnMofvGcNHeYmGVATKCpYXgc1ks5sUhCygaJpZM4OqTDw> .

-- Jessie Frazelle 4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3 pgp.mit.edu <http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3>

[grodrigues3]

I think the main thing to pay attention to is that that requires more thorough testing and documentation.

Are there PRs out with e2e/unit tests? Docs link?

[jessfraz]

There are e2e tests and unit tests that were included in the orignial PR

…

On Wed, Sep 13, 2017 at 6:16 PM, grodrigues3 ***@***.***> wrote: I think the main thing to pay attention to is that that requires more thorough testing and documentation. Are there PRs out with e2e/unit tests? Docs link? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#381 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABYNbLtuVOu9-rGfSP3SCcsArJt5GY_8ks5siFRMgaJpZM4OqTDw> .

-- Jessie Frazelle 4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3 pgp.mit.edu <http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3>

[grodrigues3]

Can you reference this issue/feature in that PR for trace-ability?

[jessfraz]

Yup will do

…

On Sep 13, 2017 18:40, "grodrigues3" ***@***.***> wrote: Can you reference this issue/feature in that PR for trace-ability? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#381 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABYNbBEQ_KVzjrbQJUMvddSPP4LV0un2ks5siFnbgaJpZM4OqTDw> .

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close