-
Notifications
You must be signed in to change notification settings - Fork 434
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
[FLINK-35937] RBAC cleanup #857
base: main
Are you sure you want to change the base?
Conversation
resources: | ||
- deployments | ||
- ingresses |
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.
If we wish to drop support for extensions/v1beta1 API version of Ingress, I think we can also remove the code in IngressUtils.java:266
. This will make the operator unable to create new Ingress resources for Kubernetes 1.19, but that version has been deprecated for a long time.
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 would appreciate getting rid of the extensions part because this is making some trouble with our deployment on a recent managed Kubernetes cluster (1.29) in combination with Kyverno policy management. Kyverno is preventing the deployment because the extensions API does not seem to exist anymore.
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.
@timsn If this is something you specifically don't need you could simply modify your downstream helm chart. But as long as we have users who need this we cannot simply remove it from the base helm template. We would need a discussion on the ML before that
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.
@gyfora thanks for your response. That's something I cannot judge because I know not enough about what the extensions are used for and if they are still in use. I just discovered that they lead to problems with our deployment process (Kyverno policy checks).
If this would brake something I would be totally fine to remove the change from this PR and do the change downstream on my own.
- apiGroups: | ||
- flink.apache.org | ||
resources: | ||
- flinkdeployments | ||
- flinkdeployments/finalizers |
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.
Won't removing finalizers here affect the fix provided in #600? The finalizers were added here specifically for OpenShift, I think it's related to the OwnerReferencesPermissionEnforcement
admission plugin.
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 the best to judge this. But at least from my point of view the "/finializers" resources are also making trouble with the deployment because it looks like the resources do not exist and (like mentioned above) Kyverno is blocking our deployment because it cannot add verbs to non existing resources. That's at least how I understand it.
Here is the output of available resources on our cluster for the flink operator:
API Resource Verbs
flink.apache.org flinkdeployments delete,deletecollection,get,list,patch,create,update,watch
flink.apache.org flinkdeployments/status get,patch,update
flink.apache.org flinkdeployments/scale get,patch,update
flink.apache.org flinksessionjobs delete,deletecollection,get,list,patch,create,update,watch
flink.apache.org flinksessionjobs/status get,patch,update
@@ -89,6 +81,7 @@ rules: | |||
- update | |||
- patch | |||
- delete | |||
- deletecollection |
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.
Why are we adding the delete collection verb to many places? Is this used somewhere?
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 just added them for "completeness". Because in the past the verbs just were a star ("*"), and deletecollection
is implicitly a part of it. If not needed, I can also remove it from this PR.
What is the purpose of the change
In further research and testing with Kyverno I figured out that some apiGroups seem to be invalid and I removed them with this PR.
It seems that the "extensions" apiGroups does not exist on our recent cluster (Kubernetes 1.29.4). I'm not sure but it might be related to these deprecation notices: https://kubernetes.io/docs/reference/using-api/deprecation-guide/#deployment-v116
Same holds for the "finalizers" resources. They do not seem to exist anymore and lead to problems with our deployment. So I also removed them.
To complete the verb list I also added "deleteCollections" where applicable.
Ref: https://issues.apache.org/jira/projects/FLINK/issues/FLINK-35310
Brief change log
Verifying this change
This change is a trivial rework / code cleanup without any test coverage.
Does this pull request potentially affect one of the following parts:
CustomResourceDescriptors
: noDocumentation
Please take a look and validate if my changes regarding the extensions and finalizers make sense to you.