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

add subprojects for sig-auth #2525

Merged
merged 2 commits into from
Nov 8, 2018

Conversation

mikedanese
Copy link
Member

Transplanted from:

https://docs.google.com/document/d/1RJvnSPOJ3JC61gerCpCpaCtzQjRcsZ2tXkcyokr6sLY/edit

I talked about this with @spiffxp in slack. Our current subprojects are generally cross cutting. The TLs for these subprojects don't roll up to specific OWNERS files generally. However, the convetions for the SIG README seems to be that subproject owners should be URLs to OWNERS files. Is this an issue?

cc @liggitt @tallclair

Fixes #2505

@k8s-ci-robot k8s-ci-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. sig/auth Categorizes an issue or PR as relevant to SIG Auth. labels Aug 13, 2018
@spiffxp
Copy link
Member

spiffxp commented Aug 13, 2018

/hold
Each subproject is supposed to be a collection of 1-N packages or repos of code, the owners which are designated by OWNERS files within those packages/repos

Where do packages like these fall within the subprojects? eg:

  • k8s.io/kubernetes/apis/authentication
  • k8s.io/kubernetes/apis/authorization
  • k8s.io/auth/authorizer
  • k8s.io/apiserver/pkg/apis/audit
  • etc.

@bgrant0607 how would you suggest proceeding here

@k8s-ci-robot k8s-ci-robot added the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 13, 2018
- Owners:
- Mike Danese
- Jordan Liggitt
- **policy-management**
Copy link
Member

Choose a reason for hiding this comment

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

Worth calling out the the policy working group (now merged with SAFE)?

Copy link
Member

Choose a reason for hiding this comment

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

(meetings field?)

Copy link
Member Author

Choose a reason for hiding this comment

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

Is this project supposed to represent a topic, or actual maintenance and development on the below subtrees? How involved is SAFE in the later?

## Subprojects

The following subprojects are owned by sig-auth:
- **audit-logging**
Copy link
Member

Choose a reason for hiding this comment

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

I think we should probably give a description (including scope) for each of these.

Copy link
Member

Choose a reason for hiding this comment

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

agree

@mikedanese
Copy link
Member Author

mikedanese commented Aug 13, 2018

@tallclair, I was working off this document:

https://docs.google.com/document/d/1RJvnSPOJ3JC61gerCpCpaCtzQjRcsZ2tXkcyokr6sLY/edit

I asked in #2505, if that was a good starting point. Perhaps we need to revisit and iterate on the document before moving subprojects to sig.yaml.

@bgrant0607
Copy link
Member

These subprojects aren't properly specified. Some of them are more activities right now than subprojects AFAIK.

We should ensure the scope in the charter is sufficient to cover them:
https://github.com/kubernetes/community/blob/master/sig-auth/charter.md

But I wouldn't list them as subprojects here unless there are specific code and/or doc artifacts.

Subprojects such as authentication, authorization, and audit logging should have specific OWNERS files. I realize they are spread out, but each subtree should be enumerated. Over time, we need to reorganize the code to be less sprawling.

Being spread out isn't the same as cross-cutting.

@mikedanese mikedanese force-pushed the auth-subprojects branch 2 times, most recently from 1808585 to 700340c Compare August 22, 2018 17:27
@k8s-ci-robot k8s-ci-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Aug 22, 2018
@spiffxp
Copy link
Member

spiffxp commented Aug 22, 2018

/approve
This looks way better, thanks. A description for these is possible if you want to go that route (eg: testing-commons). I leave the /lgtm and /hold removal to folks from the sig

@k8s-ci-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: spiffxp

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@k8s-ci-robot k8s-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 22, 2018
@mikedanese
Copy link
Member Author

mikedanese commented Aug 28, 2018

Lot's of these OWNERS files don't exist yet. If we agree on the subprojects, I will backfill them.

/hold cancel

@k8s-ci-robot k8s-ci-robot removed the do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. label Aug 28, 2018
@spiffxp
Copy link
Member

spiffxp commented Aug 31, 2018

/committee steering
(now with correct command spelling) just to keep track of when this gets closed out

@k8s-ci-robot k8s-ci-robot added the committee/steering Denotes an issue or PR intended to be handled by the steering committee. label Aug 31, 2018
@mikedanese
Copy link
Member Author

@liggitt @tallclair PTAL.

@liggitt
Copy link
Member

liggitt commented Oct 4, 2018

maintaining these is going to be tough... most of these have already link-rotted and return 404s :-/

@mikedanese
Copy link
Member Author

@liggitt These were broken when I sent the PR. My intention was to find the right subtrees to claim, then backfill the OWNERS files.

@mikedanese
Copy link
Member Author

/assign @enj @tallclair @liggitt

- https://raw.githubusercontent.com/kubernetes/kubernetes/master/staging/src/k8s.io/client-go/kubernetes/typed/authorization/OWNERS
- https://raw.githubusercontent.com/kubernetes/kubernetes/master/staging/src/k8s.io/client-go/listers/authorization/OWNERS
- **certificates**
- Description: Certificates APIs and client infrastructure to support PKI.
Copy link
Member

Choose a reason for hiding this comment

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

Can we be a bit more specific here? E.g. does kubernetes/kubernetes#63732 fall under this subproject?

Copy link
Member Author

Choose a reason for hiding this comment

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

I suspect that the linked issue would fit better under the service-accounts subproject.

- https://raw.githubusercontent.com/kubernetes/kubernetes/master/staging/src/k8s.io/apiserver/pkg/authentication/request/x509/OWNERS
- https://raw.githubusercontent.com/kubernetes/kubernetes/master/staging/src/k8s.io/client-go/util/cert/OWNERS
- https://raw.githubusercontent.com/kubernetes/kubernetes/master/staging/src/k8s.io/client-go/util/certificate/OWNERS
- **encryption-at-rest**
Copy link
Member

Choose a reason for hiding this comment

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

Can we expand this subproject to be "secrets management"? E.g. I think the vault integration might fall under this subproject?

Copy link
Member Author

Choose a reason for hiding this comment

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

The current implementation of encryption is orthogonal to resource kind even though the motivating usecase was secrets. Which vault integration are you thinking of? The KMS plugin? There's also a valut integration based on service accounts.

@k8s-ci-robot k8s-ci-robot added sig/contributor-experience Categorizes an issue or PR as relevant to SIG Contributor Experience. sig/testing Categorizes an issue or PR as relevant to SIG Testing. labels Nov 2, 2018
so block descriptions look the same as inline descriptions.
@liggitt
Copy link
Member

liggitt commented Nov 2, 2018

created approvers and reviewers owners aliases for each subproject, and linked them in owners files in the referenced packages in kubernetes/kubernetes#70600

- Description: Node identity management (co-owned with sig-lifecycle), and authorization restrictions for isolating workloads on separate nodes (co-owned with sig-node).
- Owners:
- https://raw.githubusercontent.com/kubernetes/kubernetes/master/pkg/controller/certificates/approver/OWNERS
- https://raw.githubusercontent.com/kubernetes/kubernetes/master/pkg/kubelet/certificate/OWNERS
Copy link
Member

@liggitt liggitt Nov 7, 2018

Choose a reason for hiding this comment

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

the first two seem more like the certificates subproject (and pkg/controller/certificates is already under the certificates subproject)

Copy link
Member Author

@mikedanese mikedanese Nov 8, 2018

Choose a reason for hiding this comment

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

pkg/kubelet/certificate belongs under certificate infra over node identity? And the approvers in pkg/controller/certificates/approver are only good for approving node certificates. These both seem more appropriately positioned here.

Copy link
Member

Choose a reason for hiding this comment

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

ok, I can buy that. can you follow up with a PR against k/k to populate/fixup those two OWNERS files to point to the right subproject?

@liggitt
Copy link
Member

liggitt commented Nov 7, 2018

with the switch of the certificates bits under the certificates subproject, this lgtm as a first step

the referenced owners files have been added in kubernetes/kubernetes#70600

@liggitt
Copy link
Member

liggitt commented Nov 8, 2018

/lgtm

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Nov 8, 2018
@k8s-ci-robot k8s-ci-robot merged commit d5e1a9b into kubernetes:master Nov 8, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. committee/steering Denotes an issue or PR intended to be handled by the steering committee. lgtm "Looks good to me", indicates that a PR is ready to be merged. sig/auth Categorizes an issue or PR as relevant to SIG Auth. sig/contributor-experience Categorizes an issue or PR as relevant to SIG Contributor Experience. sig/testing Categorizes an issue or PR as relevant to SIG Testing. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants