Skip to content
This repository has been archived by the owner on Oct 21, 2020. It is now read-only.

cephfs provisioner leaks Secret objects #455

Closed
farcaller opened this issue Nov 11, 2017 · 5 comments
Closed

cephfs provisioner leaks Secret objects #455

farcaller opened this issue Nov 11, 2017 · 5 comments
Assignees
Labels
help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.

Comments

@farcaller
Copy link
Contributor

The cephfs provisioner doesn't clean up Secret objects (doesn't re-use them either), and doesn't clean up the actual users from ceph, leaving them dangling with some permissions:

client.kubernetes-dynamic-user-8e229ae4-c4a5-11e7-ad64-0adc8221b842
	key: 
	caps: [mds] allow r
	caps: [mon] allow r
	caps: [osd]

Instead the provisioner should return the storage to the same state it was before the PVC was created.

@wongma7
Copy link
Contributor

wongma7 commented Nov 12, 2017

/assign @rootfs
kind of related, we should no longer be creating secrets in same namespace as pvc anyhow: #309

@wongma7 wongma7 added the help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. label Nov 12, 2017
@rootfs
Copy link
Contributor

rootfs commented Nov 13, 2017

the provisioner deauthorize the user when deleting the share.

Maybe the cap is not all that is expected in the library here, since mds is given allow r here to work around a kernel cephfs issue.

@rootfs
Copy link
Contributor

rootfs commented Nov 14, 2017

@cofyc do you have a chance to look into this? thanks

@cofyc
Copy link
Contributor

cofyc commented Nov 15, 2017

@rootfs
OK, I will take a look at it.

@JrCs
Copy link
Contributor

JrCs commented Nov 16, 2017

My PR #466 only remove ceph user if it's name start with kubernetes-dynamic-user-

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.
Projects
None yet
Development

No branches or pull requests

5 participants