Skip to content
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

Merged
merged 1 commit into from Oct 11, 2021

Conversation

rolinh
Copy link
Member

@rolinh rolinh commented Sep 10, 2021

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.

@rolinh rolinh added release-note/misc This PR makes changes that have no direct user impact. area/helm Impacts helm charts and user deployment experience labels Sep 10, 2021
@rolinh rolinh requested a review from a team as a code owner September 10, 2021 19:49
@rolinh rolinh requested review from a team, kaworu and nathanjsweet September 10, 2021 19:49
Copy link
Member

@joestringer joestringer left a 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?

@rolinh
Copy link
Member Author

rolinh commented Sep 10, 2021

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.

@rolinh
Copy link
Member Author

rolinh commented Sep 10, 2021

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

K8sDatapathConfig AutoDirectNodeRoutes Check connectivity with sockops and direct routing

Failure Output

FAIL: Error creating resource /home/jenkins/workspace/Cilium-PR-K8s-1.19-kernel-5.4/src/github.com/cilium/cilium/test/k8sT/manifests/l3-policy-demo.yaml: Cannot retrieve cilium pod cilium-nctq6 policy revision: cannot get revision from json output '': could not parse JSON from command "kubectl exec -n kube-system cilium-nctq6 -- cilium policy get -o json"

If it is a flake, comment /mlh new-flake Cilium-PR-K8s-1.19-kernel-5.4 so I can create a new GitHub issue to track it.

@rolinh
Copy link
Member Author

rolinh commented Sep 13, 2021

/mlh new-flake Cilium-PR-K8s-1.19-kernel-5.4

👍 created #17373

Copy link
Member

@tklauser tklauser left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Member

@kaworu kaworu left a 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!

@kaworu
Copy link
Member

kaworu commented Sep 14, 2021

It seems that these volumes were wrongly given permission 420 instead of 0400, giving write permission to the group

Actually, 420 is in decimal so before this patch the defaultMode expressed in octal would be 0644.

tklauser added a commit to cilium/cilium-cli that referenced this pull request Sep 14, 2021
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>
@tklauser
Copy link
Member

tklauser commented Sep 14, 2021

tklauser added a commit to cilium/cilium-cli that referenced this pull request Sep 14, 2021
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>
Copy link
Member

@joestringer joestringer left a 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.

@rolinh
Copy link
Member Author

rolinh commented Sep 15, 2021

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.

Note that the JSON spec doesn't support octal notation, so use the value 256 for 0400 permissions. If you use YAML instead of JSON for the Pod, you can use octal notation to specify permissions in a more natural way.

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.

@rolinh rolinh force-pushed the pr/rolinh/helm-volumes-defaultmode branch 2 times, most recently from 49352a2 to 50e5ae1 Compare September 15, 2021 08:50
Copy link
Member

@joestringer joestringer left a 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. 👍

@kaworu
Copy link
Member

kaworu commented Sep 16, 2021

@joestringer Sorry, my comment was incomplete. My guess is that the decimal 420 was meant to be 0420, as (1) 420=0644 is the default (thanks @rolinh for pointing it out) and (2) we have an actual 0420 in install/kubernetes/cilium/templates/clustermesh-apiserver/deployment.yaml.

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):

[…] It seems that these volumes were wrongly given permission 420 (420 decimal == 0644 octal) instead of 0400

Did you meant instead of 0420 instead?

@rolinh
Copy link
Member Author

rolinh commented Sep 16, 2021

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

K8sDatapathConfig Host firewall Check connectivity with IPv6 disabled

Failure Output

FAIL: Pods are not ready in time: timed out waiting for pods with filter  to be ready: 4m0s timeout expired

If it is a flake, comment /mlh new-flake Cilium-PR-K8s-GKE so I can create a new GitHub issue to track it.

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>
@rolinh rolinh force-pushed the pr/rolinh/helm-volumes-defaultmode branch from 50e5ae1 to dd28406 Compare October 4, 2021 13:02
@rolinh
Copy link
Member Author

rolinh commented Oct 4, 2021

/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)

@rolinh
Copy link
Member Author

rolinh commented Oct 5, 2021

ci-aks

@aanm aanm merged commit 6f0a866 into master Oct 11, 2021
@aanm aanm deleted the pr/rolinh/helm-volumes-defaultmode branch October 11, 2021 23:25
aditighag pushed a commit to aditighag/cilium-cli that referenced this pull request Apr 21, 2023
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>
michi-covalent pushed a commit to michi-covalent/cilium that referenced this pull request May 30, 2023
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/helm Impacts helm charts and user deployment experience release-note/misc This PR makes changes that have no direct user impact.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants