-
Notifications
You must be signed in to change notification settings - Fork 142
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
feat: add support for confidential pods #1971
feat: add support for confidential pods #1971
Conversation
Welcome @arc9693! |
Hi @arc9693. Thanks for your PR. I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
@arc9693 thanks for the PR, can you sign the cla license first? thx |
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.
Thank you @arc9693! I left a few comments 🙂
@andyzhangx Do note this is does NOT implement data or secret confidentiality at this point - this is for unblocking the initial use case where customers want to use non-confidential storage inside confidential pods.
55c4aba
to
76f0471
Compare
pkg/azurefile/nodeserver.go
Outdated
klog.V(2).Infof("NodeStageVolume: mount info for volume %s is already present on %s", volumeID, targetPath) | ||
} else { // if not mounted, save mountInfo.json | ||
mountFsType := cifs | ||
ipAddr, err := net.ResolveIPAddr("ip", server) |
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.
This is needed as of now, because inside a kata-cc pod, the kata agent (using nix:mount rust crate) performs the CIFS mount and it fails with EHOSTUNREACH, even though a command line mount -t cifs
succeeds on the same VM.
Kata-agent mount reference: https://github.com/microsoft/kata-containers/blob/386cab09d8c544097f47c60591b283cff2397439/src/agent/src/mount.rs#L107
nix:mount function reference: https://docs.rs/nix/latest/src/nix/mount/linux.rs.html#104-133
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-to-test
dc2d0ae
to
e76a9a3
Compare
e76a9a3
to
6166a27
Compare
5a4b095
to
443eb20
Compare
/retest |
1 similar comment
/retest |
could you fix the windows ut failure:
|
tar file update go mod vendor
94cd145
to
2275edd
Compare
7d93b9c
to
c788daa
Compare
c788daa
to
d3da6b2
Compare
d3da6b2
to
3ddde6b
Compare
/retest |
/retest |
1 similar comment
/retest |
…-azurefile-csi-driver into archana1/cc-azurefile
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.
/lgtm
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: andyzhangx, arc9693 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 |
What type of PR is this?
/kind feature
What this PR does / why we need it:
Kata-cc is a lightweight VM based runtime for containers. As of now, the azurefile-csi-driver’s persistent storage does not work for kata-cc or confidential pods. The file sharing between host and guest is disabled and therefore the SMB mount on host node does not propagate as expected for the pod.
The proposed changes enable the SMB mount inside the guest VM that wraps the confidential pod.
enableKataCCMount
astrue
in storage class or PV:Which issue(s) this PR fixes:
Fixes #
Requirements:
Special notes for your reviewer:
Release note: