-
Notifications
You must be signed in to change notification settings - Fork 5.2k
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
Conversation
/hold Where do packages like these fall within the subprojects? eg:
@bgrant0607 how would you suggest proceeding here |
- Owners: | ||
- Mike Danese | ||
- Jordan Liggitt | ||
- **policy-management** |
There was a problem hiding this comment.
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)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(meetings field?)
There was a problem hiding this comment.
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** |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree
@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. |
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: 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. |
1808585
to
700340c
Compare
700340c
to
8634d5c
Compare
/approve |
[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 |
Lot's of these OWNERS files don't exist yet. If we agree on the subprojects, I will backfill them. /hold cancel |
/committee steering |
@liggitt @tallclair PTAL. |
maintaining these is going to be tough... most of these have already link-rotted and return 404s :-/ |
8634d5c
to
07f27f9
Compare
@liggitt These were broken when I sent the PR. My intention was to find the right subtrees to claim, then backfill the OWNERS files. |
07f27f9
to
8dfc700
Compare
8dfc700
to
089fbe1
Compare
/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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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** |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
a1ac21b
to
157cbc7
Compare
157cbc7
to
8dfd31a
Compare
so block descriptions look the same as inline descriptions.
8dfd31a
to
fa386fb
Compare
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 |
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
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 |
/lgtm |
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