-
Notifications
You must be signed in to change notification settings - Fork 722
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
Add PodSecurityPolicies for rancher-istio,rancher-tracing and kiali #957
Add PodSecurityPolicies for rancher-istio,rancher-tracing and kiali #957
Conversation
27f7c7f
to
e8c95c6
Compare
Just hit I'm assuming this issue on my test cluster. Deployed with RKE using the permissive PSP. Blocks any sort of ISTIO deployment on a vaguely sensible set of defaults. Would be great to see this available ASAP |
@bashofmann I pointed your current PR back to |
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 content-wise, but this needs to be rebased on the current Istio chart(s) + scripts.
@brendarearden can you help get this PR updated / merged in?
e8c95c6
to
a7b5af6
Compare
I rebased the PR and added the requested newline |
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, nit changes suggested
packages/rancher-kiali-server/generated-changes/overlay/templates/psp.yaml
Outdated
Show resolved
Hide resolved
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!! Thank you for doing this change!!
@bashofmann @brendarearden @aiyengar2 Is this ready to merge after a rebase? I'm cleaning up this repo and just want to make sure we don't lose track of this. |
@pennyscissors thanks for bumping this. Let’s hold off till 2.5.6 is released. @bashofmann sorry to ask once more, but can you rebase this PR one more time? Since this should (presumably) be targeted for 2.5.7, we’ll need to bump all the packageVersions by 1 and reset all the releaseCandidateVersions of charts that are being modified to 00. @brendarearden could you help merge this in as soon as we’re clear to merge 2.5.7 changes so we can avoid another rebase? We should probably also check with QA / management w.r.t. whether QA has bandwidth to test this issue for the next release. |
Can I asked whats the reason for waiting until 2.5.7? This is currently broken for production for everybody that runs PSPs enabled. Assuming 2.5.7 will likely be a way off yet |
aed1108
to
3422f84
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.
LGTM w.r.t. the content of the PR, but I have some questions regarding Istio / Tracing / Kiali conventions. Will approve and leave those choices up to Brenda.
packages/rancher-kiali-server/generated-changes/overlay/templates/psp.yaml
Outdated
Show resolved
Hide resolved
@@ -1,3 +1,3 @@ | |||
url: local | |||
packageVersion: 02 | |||
packageVersion: 03 |
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.
@brendarearden should we be bumping the packageVersion here or should we just modify the Chart.yaml version to release a new version and reset these to 00 / 00?
@cbron this might also be a question for you: for local charts, what should our convention be w.r.t. bumping packageVersion v.s. bumping the major.minor.patch version? For pushprox, I'm leaning towards never touching the packageVersion and only touching the major.minor.patch + releaseCandidate version, re: this comment.
@haswalt we need QA bandwidth to test the contents of this PR before release (outside of a developer review) to ensure that it fully addresses all test cases in the original issue |
@aiyengar2 understood thank you |
I am about to split istio into 1.8 and 1.9 version and I am hoping we can merge this ASAP so that both version work in an airgap environment. @bashofmann how likely is it that we could get the nits fixed and then updated with the current branch by tomorrow? |
Should be doable, I have a bit of time tomorrow morning. |
3422f84
to
1ddcaf6
Compare
I replaced the hardcoded names and namespace with the appropriate templates. |
packages/rancher-kiali-server/generated-changes/overlay/templates/psp.yaml
Outdated
Show resolved
Hide resolved
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.
The naming on the resources needs fixed, if you want to go ahead and fix the new line nit at the same time I think we will be good to go.
…-kiali-server Signed-off-by: Bastian Hofmann <[email protected]>
1ddcaf6
to
4096e77
Compare
Sorry, I missed that. Done. |
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
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.
FYI @brendarearden I don't want to block this PR on nit changes, but we should eventually make changes to Istio / Kiali / Tracing to follow consistent Helm chart conventions.
Some changes I think we should consider:
- Istio uses raw names (i.e. psp-istio-cni) across the chart, whereas tracing + kiali use helper template. I think we should move Istio towards using helper template based naming as well.
- labels like app / heritage / release should also be in a helper template, since it's copy/pasted across several resources within tracing. Maybe we should also add those labels to Istio / Kiali
Let's get this merged! 🎉
@@ -13,7 +13,7 @@ annotations: | |||
catalog.cattle.io/release-name: rancher-istio | |||
catalog.cattle.io/ui-component: istio | |||
catalog.cattle.io/provides-gvr: networking.istio.io.virtualservice/v1beta1 | |||
catalog.cattle.io/auto-install: rancher-kiali-server-crd=1.29.000-rc00 | |||
catalog.cattle.io/auto-install: rancher-kiali-server-crd=1.29.001-rc00 |
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 less for review and more for understanding: what does this annotation do?
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.
rancher-istio has a dependency on rancher-kiali-server, which has a CRD chart. Since this means that rancher-istio needs to install rancher-kiali-server-crd automatically on the UI in order to have access, we need to add this annotation.
This type of dependency on another package's CRD chart is not very neatly handled by the charts-build-scripts today, which is why we need to manually add this annotation.
Added an issue at rancher/charts-build-scripts#28 to address this.
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.
Gotcha - thanks for the echo issue. Both the manual approach and the proposed one in the issue make sense.
apiVersion: policy/v1beta1 | ||
kind: PodSecurityPolicy | ||
metadata: | ||
name: psp-istio-cni |
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.
Wondering if we should expose this in values.yaml
(and its references throughout the other file(s))
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.
Do you mean exposing a field that allows you to enable or disable deploying PSPs? I kinda agree with this idea since I think this is what rancher-monitoring does too:
pspEnabled: true |
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.
I mean both the naming and that :)
I think it may be a good idea.
apiVersion: rbac.authorization.k8s.io/v1 | ||
kind: RoleBinding | ||
metadata: | ||
name: psp-istio-cni |
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.
Wondering if we should expose this in values.yaml
(and its references throughout the other file(s))
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.
w.r.t. naming, I think we just need to introduce a helper template instead of hard-coding the name, re: my comment in #957 (review). Not worth blocking this PR for though.
What else would you want to expose in the values.yaml?
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.
I'm hesitant to open up values.yaml fields unless absolutely necessary since it just adds more stuff we need to test / support per release.
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.
Agreed on not blocking the PR for it, but the template
may suffice. Agreed on the values.yaml
though; just want to anticipate potential tech debt if naming is a bottleneck or a user wants to bring their own RBAC (unlikely)
seLinux: | ||
rule: RunAsAny |
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 should probably be overrideable in values.yaml
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.
I'm not sure if we want to expose fields to configure the PSP used by Istio itself; is this something that other Helm charts expose today?
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.
I'm moreso curious if we should expose SELinux values. This might change dependent on how the node is configured and the customer use case. However, this might be a paranoid concern
packages/rancher-kiali-server/generated-changes/overlay/templates/psp.yaml
Show resolved
Hide resolved
Closing because PSPs have been merged with #1071 |
Add PodSecurityPolicies for rancher-istio, rancher-tracing and rancher-kiali-server.
Addresses: rancher/rancher#30744
Rebase of #930