Provision volumes from cross-namespace snapshots

[mkimuram]

Enhancement Description

• One-line enhancement description (can be used as a release note): Provision volumes from cross-namespace snapshots
• Kubernetes Enhancement Proposal: https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/3294-provision-volumes-from-cross-namespace-snapshots
• Discussion Link: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#bookmark=id.y643l0tnnycj
• Primary contact (assignee): @ttakahashi21 @mkimuram
• Responsible SIGs: @kubernetes/sig-storage-feature-requests
• Enhancement target (which target equals to which milestone):
  • Alpha release target (x.y): v1.26
  • Beta release target (x.y): v1.28
  • Stable release target (x.y): v1.30
• Alpha
  • KEP (k/enhancements) update PR(s): KEP-3294: Add proposal for provisioning volumes from cross-namespace snapshots #3295
  • Code (k/k) update PR(s):
    • API change: Introduce APIs to support CrossNamespaceVolumeDataSource kubernetes#113186
  • Code (kubernetes-csi/external-provisioner): Alpha support for provision volumes from cross-namespace data sources kubernetes-csi/external-provisioner#805
  • Docs (k/website) update PR(s):
    • Adding Feature gate/Updating Kubernetes Documentation/Concepts/Storage/Persistent Volumes: Add document for Provision volumes from cross namespace data sources website#37802
    • Blog: Add blog post for Provision volumes from cross namespace data sources website#37628
• Beta
  • KEP (k/enhancements) update PR(s): TBD
  • Code (k/k) update PR(s):
    • Add APIGroup ratcheting validation to PVC.DataSource kubernetes#113798
    • E2E tests: TBD
    • Feature gate change: TBD
    • Blockers:
      • Referential Authorization #3766
  • Docs (k/website) update(s): TBD

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

[xing-yang]

/milestone v1.25

[Priyankasaggu11929]

Hello @mkimuram 👋, 1.25 Enhancements team here.

Just checking in as we approach enhancements freeze on 18:00 PST on Thursday June 16, 2022.

For note, This enhancement is targeting for stage alpha for 1.25 (correct me, if otherwise)

Here's where this enhancement currently stands:

• KEP file using the latest template has been merged into the k/enhancements repo.
• KEP status is marked as implementable
• KEP has a updated detailed test plan section filled out
• KEP has up to date graduation criteria
• KEP has a production readiness review that has been completed and merged into k/enhancements.

Looks like for this one, we would need to update the open KEP PR #3295 for the following:

• update the README.md to incorporate required more details in the Test Plan section, in furtherance of the goal of increasing reliability across the project.

For note, the status of this enhancement is marked as at risk. Please keep the issue description up-to-date with appropriate stages as well. Thank you!

[Priyankasaggu11929]

Hello @mkimuram 👋, just a quick check-in again, as we approach the 1.25 enhancements freeze.

Please plan to get the above criterias done before the upcoming enhancements freeze on Thursday, June 16, 2022 at 18:00 PM PT.

For note, the current status of the enhancement is at at-risk. Thank you!

[Priyankasaggu11929]

Hello @mkimuram 👋, another check-in, as we approach the 1.25 enhancements freeze.

All required criteria are fulfilled by the open PR #3295.

We just now require merging it before enhancements freeze on Thursday, June 23, 2022 at 18:00 PM PT, which is just over 3 days away from now.

For note, the current status of the enhancement is atat-risk. Thank you!

[Priyankasaggu11929]

Hello, 1.25 Enhancements Lead here 👋. With Enhancements Freeze now in effect, this enhancement has not met the criteria for the freeze and has been removed from the milestone.

As a reminder, the criteria for enhancements freeze is:

• KEP file using the latest template has been merged into the k/enhancements repo, with up to date latest milestone and stage
• KEP status is marked as implementable
• KEP has an updated detailed test plan section filled out
• KEP has up to date graduation criteria
• KEP has a production readiness review that has been completed and merged into k/enhancements.

Feel free to file an exception to add this back to the release. If you plan to do so, please file this as early as possible.

Thanks!
/milestone clear

[xing-yang]

/milestone v1.25

[xing-yang]

/milestone v1.26

[xing-yang]

/assign @ttakahashi21

[k8s-ci-robot]

@xing-yang: GitHub didn't allow me to assign the following users: ttakahashi21.

Note that only kubernetes members, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

/assign @ttakahashi21

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[kikisdeliveryservice]

This issue should remain open so long as the feature isn't deprecated or graduated to GA.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ttakahashi21]

/assign @ttakahashi21
/reopen

It is currently under discussion.
#3294 (comment)

[k8s-ci-robot]

@ttakahashi21: Reopened this issue.

In response to this:

/assign @ttakahashi21
/reopen

It is currently under discussion.
#3294 (comment)

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[sgielen]

/reopen
/remove-lifecycle rotten

This is still awaiting #4387, which is currently still progressing.

[k8s-ci-robot]

@sgielen: You can't reopen an issue/PR unless you authored it or you are a collaborator.

In response to this:

/reopen
/remove-lifecycle rotten

This is still awaiting #4387, which is currently still progressing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ttakahashi21]

/reopen

[k8s-ci-robot]

@ttakahashi21: Reopened this issue.

In response to this:

/reopen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[ttakahashi21]

@liggitt @deads2k @enj @robscott

Is my understanding right that CrossNamespaceVolumeDataSource feature can be implemented with AuthorizeWithSelectors feature(*1)(*2), instead of ReferenceGrant?

(*1)Authorize with Field and Label Selectors

(*2)Using Node Authorization

[liggitt]

Is my understanding right that CrossNamespaceVolumeDataSource feature can be implemented with AuthorizeWithSelectors feature(*1)(*2), instead of ReferenceGrant?

I'm not sure what this feature was planning to use reference grant for. The field/label selector authorization feature just makes selectors visible to authorization. The node authorization feature only applies to kubelet API clients. There is not yet a way to selectively grant selector-based authorization to arbitrary users / clients.

[ttakahashi21]

With this feature enabled, you specify a namespace in the dataSourceRef field of a new PersistentVolumeClaim.
Once CSI provisioner confirms that the DataSource(PVC, VolumeSnapshot ,AnyVolumeDatasource) is allowed to access via the ReferenceGrant. If access is OK, the new PersistentVolume can populate its data from the storage source specified in that other namespace.

I thought this was #4601 that was implemented instead of #4387, am I correct in my understanding?

[liggitt]

Once CSI provisioner confirms that the DataSource(PVC, VolumeSnapshot ,AnyVolumeDatasource) is allowed to access via the ReferenceGrant

I'm not aware of any work or design to frame that authorization check in terms of field or label selectors, so I'm not sure how #4601 would impact this feature.

I thought this was #4601 that was implemented instead of #4387, am I correct in my understanding?

#4601 was implemented as a first step and possible building block in a reference grant design.