-
Notifications
You must be signed in to change notification settings - Fork 17
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
Could not resize Luks volume ? #812
Comments
It seems that it's a feature that has been implemented in earlier release. |
Hello, i had the same problem but i solved it. Here how i did: Prerequisite
How to do
Little analysisI think that the increasing size of the volume goes well. After increasing the pvc size, i manually mount the outscale disk on a VM and everything was ok. But when i launched the pod i had the same error has you with Luks encryption. Hope this help you |
Well, it should work without all this steps. |
#814 PR already done |
Hello, Will you release soon? |
Hello, any update for the new release ? |
Hello, just try with new release, I could not even mount luks volume :( |
I have used same storageclass that described at the beginning of this post.
|
And in debug mode:
|
Hello, Also, As part of this release, we have successfully upgraded the external resizer component from v1.3.0 to v1.11.2 but this is not enough to support resizing volumes while they are in use (attached to running instances or pods). Currently, volumes must be in an "available" state, meaning they need to be detached or not actively used by a running process to resize them successfully. |
Hello, I use version 1.4.0.
|
Ok thanks for your fast reply, I tested with your sc.yaml and I got this: {"Volumes":[{"VolumeId":"vol-3ad55aeb","Tags":[{"Value":"pvc-40392a8a-761a-4e68-89af-ee7cd9b3ed00","Key":"CSIVolumeName"}],"VolumeType":"gp2","SubregionName":"eu-west-2a","State":"in-use","CreationDate":"2024-10-19T14:04:50.502Z","Iops":100,"LinkedVolumes":[{"VolumeId":"vol-3ad55aeb","DeleteOnVmDeletion":false,"DeviceName":"/dev/xvdb","State":"attached","VmId":"i-777c3253"}],"Size":1}],"ResponseContext":{"RequestId":"983e9a18-289d-435f-9c05-95d94765679f"}} But I will look again and will be back to you ASAP |
But this error message indicate you are trying to resize volume which is currently attached to a Pod no ? apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: gp2-delete-immediate-encrypted-ext4
allowVolumeExpansion: true
parameters:
encrypted: 'true'
luks-cipher: aes-xts-plain64
csi.storage.k8s.io/node-stage-secret-name: luks-key
csi.storage.k8s.io/node-stage-secret-namespace: kube-system
csi.storage.k8s.io/provisioner-secret-name: osc-csi-bsu
csi.storage.k8s.io/provisioner-secret-namespace: kube-system
csi.storage.k8s.io/fstype: ext4
type: gp2
provisioner: bsu.csi.outscale.com
reclaimPolicy: Delete
volumeBindingMode: Immediate and by creating the following Secrets: apiVersion: v1
kind: Secret
metadata:
name: luks-key
type: Opaque
stringData:
key: xxxxxxxxxxxxx # Your luks key
---
apiVersion: v1
kind: Secret
metadata:
name: osc-csi-bsu
namespace: kube-system
labels:
app.kubernetes.io/instance: osc-bsu-csi-driver
app.kubernetes.io/managed-by: Helm
app.kubernetes.io/name: osc-bsu-csi-driver
app.kubernetes.io/version: v1.2.4
helm.sh/chart: osc-bsu-csi-driver-1.6.0
annotations:
meta.helm.sh/release-name: osc-bsu-csi-driver
meta.helm.sh/release-namespace: kube-system
stringData:
access_key: xxxxxxxxxxxxxxxxxxxxx
secret_key: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
type: Opaque |
Hello again, Key Improvements: Running containers as a non-root user: This reduces the risk of privilege escalation and limits what the container can do within the host system. Seccomp Profile (RuntimeDefault): The seccomp profile restricts the system calls that containers can make, preventing potentially dangerous or unnecessary interactions with the host operating system. AllowPrivilegeEscalation: false: ReadOnlyRootFilesystem: Consider Privileged Mode: If the CSI driver or container needs access to device drivers, encryption tools, or the kernel, you may need to run the container in privileged mode. You can enable this by setting privileged: true in the container securityContext. Example: Start by allowing privilege escalation (allowPrivilegeEscalation: true) to see if that resolves the issue. If not, try temporarily enabling privileged: true to diagnose whether the issue is related to insufficient permissions. if privileged access proves necessary, you can then decide on how to minimize the use of privileged mode in the long run by refining the security settings or applying it selectively. (If the problem persist can you please open a new ticket) |
Hello, I clearly understand the non-root user benefit. |
Hello, DaemonSet (Node-specific operations):
Only the Node Driver in the DaemonSet typically requires privileged: true (where the actual mount occurs), you need to allow privileged access by setting allowPrivilegeEscalation: true or allowing the node container to run as privileged (privileged: true).
This ensures that only the Node Driver has privileged access, while other components operate with minimal privileges. |
Ah thanks a lot for your explanation :) |
Hello, not sure to understand this : #835 ? osc-bsu-csi-driver/osc-bsu-csi-driver/values.yaml Lines 228 to 233 in ca69078
|
Hello #835 I pushed this PR to help you set the right permissions to handle encrypted volumes |
Maybe you should check another time, as it's under serviceAccount:
serviceAccount:
controller:
# -- Annotations to add to the Controller ServiceAccount
annotations: {}
# securityContext on the controller container (see sidecars for securityContext on sidecar containers)
containerSecurityContext:
seccompProfile:
type: RuntimeDefault
readOnlyRootFilesystem: true
allowPrivilegeEscalation: false |
With your latest commits, I have successfully mounted luks volume (securitycontext issue).
|
I have finally found the issue I think. Thanks a lor for your patience :) |
Hello So to summarize Seccomp Profile and Privilege Escalation: For the node, the containerSecurityContext includes privileged: true and seccompProfile: Unconfined, which is essential if you're interacting with encrypted LUKS volumes and need full access to system resources. |
It's safe and clear, thanks again for the clarification 😊 |
Hello, |
Hello @albundy83 sorry I was off, I will work in this this week. |
PR done to fix the resize #839 |
Ah perfect, will you release a version or should we try it like this ? |
yes I will release soon for sure, but you can test if you want |
It works !!!!!! |
/kind bug
What happened?
Hello, I have tried to increase PVC volume size but it just fails :(
Here the error message :
If I can provide you more details, just tell me :-)
What you expected to happen?
Could not resize Luks volumeolume resized
How to reproduce it (as minimally and precisely as possible)?
Here the storageclass I have used (I have tried with both ext4 and xfs):
Anything else we need to know?:
Environment
kubectl version
):Client Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.15", GitCommit:"fb63712e1d017142977e88a23644b8e48b775665", GitTreeState:"clean", BuildDate:"2024-06-11T20:04:38Z", GoVersion:"go1.21.11", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v5.0.1
Server Version: version.Info{Major:"1", Minor:"27", GitVersion:"v1.27.15+rke2r1", GitCommit:"fb63712e1d017142977e88a23644b8e48b775665", GitTreeState:"clean", BuildDate:"2024-06-19T05:07:04Z", GoVersion:"go1.21.11 X:boringcrypto", Compiler:"gc", Platform:"linux/amd64"}
The text was updated successfully, but these errors were encountered: