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
helm: ensure defaultMode=0400 for projected volumes containing secrets #17367
Conversation
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.
Looks right to me, I assume that CI should complain if there's any real problem with these permission changes?
That's my assumption, yes. |
test-me-please Job 'Cilium-PR-K8s-1.19-kernel-5.4' failed and has not been observed before, so may be related to your PR: Click to show.Test Name
Failure Output
If it is a flake, comment |
/mlh new-flake Cilium-PR-K8s-1.19-kernel-5.4 👍 created #17373 |
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.
Nice catch. I think we have the same issue in cilium-cli:
https://github.com/cilium/cilium-cli/blob/master/install/install.go#L40
https://github.com/cilium/cilium-cli/blob/master/clustermesh/clustermesh.go#L49
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.
Thanks for the patch!
Actually, |
Follow cilium/cilium#17367: It seems that these volumes were wrongly given permission 420 instead of 0400, giving write permission to the group. In all instances, the actual volumeMounts were set to readonly so this change should have no effect but better be more cautious about permissions for secrets. Reported-by: Robin Hahling <robin.hahling@gw-computing.net> Signed-off-by: Tobias Klauser <tobias@cilium.io>
cilium/cilium-cli#539 should address this |
Follow cilium/cilium#17367: It seems that these volumes were wrongly given permission 420 instead of 0400, giving write permission to the group. In all instances, the actual volumeMounts were set to readonly so this change should have no effect but better be more cautious about permissions for secrets. Reported-by: Robin Hahling <robin.hahling@gw-computing.net> Signed-off-by: Tobias Klauser <tobias@cilium.io>
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.
Given Alex's report that these YAML values do not support Octal and the previous values were decimal (and correct), it sounds like we shouldn't push forward with this.
I'm not sure I follow. Alex's point is that these permissions were probably inadvertently decimal instead of octal because of the missing leading 0. The decimal value 420 happens to be 0644 octal which is the default value if not specified. However, I think that what we probably want is actually 0400, as per this PR change, as YAML supports octal notation.
I will however update the PR to add a note that the leading 0 is actually important. EDIT: I also updated the commit message to take into account Alex's comment. |
49352a2
to
50e5ae1
Compare
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 yeah my misunderstanding then. 👍
@joestringer Sorry, my comment was incomplete. My guess is that the decimal In any case, I still think the PR is correct and improving the situation. However, it's a "bigger change" than we originally thought it was. @rolinh From the commit message (emphasis mine):
Did you meant instead of 0420 instead? |
test-me-please Job 'Cilium-PR-K8s-GKE' failed and has not been observed before, so may be related to your PR: Click to show.Test Name
Failure Output
If it is a flake, comment Job 'Cilium-PR-K8s-1.16-net-next' hit: #17176 (85.97% similarity) |
It seems that these volumes were wrongly given permission 420 (420 decimal == 0644 octal) instead of 0400, meaning that they were world readable and user writable. Secrets should only be readable by the actual user, thus with permission 0400. Signed-off-by: Robin Hahling <robin.hahling@gw-computing.net>
50e5ae1
to
dd28406
Compare
/test Job 'Cilium-PR-K8s-GKE' has 1 failure but they might be new flake since it also hit 1 known flake: #17403 (80.36) |
ci-aks |
Follow cilium/cilium#17367: It seems that these volumes were wrongly given permission 420 instead of 0400, giving write permission to the group. In all instances, the actual volumeMounts were set to readonly so this change should have no effect but better be more cautious about permissions for secrets. Reported-by: Robin Hahling <robin.hahling@gw-computing.net> Signed-off-by: Tobias Klauser <tobias@cilium.io>
Follow cilium#17367: It seems that these volumes were wrongly given permission 420 instead of 0400, giving write permission to the group. In all instances, the actual volumeMounts were set to readonly so this change should have no effect but better be more cautious about permissions for secrets. Reported-by: Robin Hahling <robin.hahling@gw-computing.net> Signed-off-by: Tobias Klauser <tobias@cilium.io>
It seems that these volumes were wrongly given permission
420
(420
decimal ==0644
octal) instead of0400
, meaning that they were world readable and user writable. Secrets should only be readable by the actual user, thus with permission0400
.