Repository navigation
Conversation
This simplifies the network policy and also makes it explicit which pod shall have ingress access to the database.
Notebooks have been removed.
In this particular case the init job. This will allow to reduce the access surface later.
That service does not exist anymore. Do not mix it up with `renku-k8s-watcher`.
Label: - renku-data-service - renku-data-tasks with renku.io/solr-access: "true"
Label: - renku-data-service - renku-data-tasks - uiserver - gateway with renku.io/redis-access: "true" This is independent from the redis.clientLabel which may or may not be required based on how the redis deployment was done.
Label: - renku-data-service - renku-data-tasks with renku.io/authz-access: "true"
There are no notebooks anymore.
Added to: - gateway - swagger - keycloak - ui (client and server)
This replaces several of the "from anywhere" policies.
Add exactly which pods they are allowed to access
There's no need to go through the ingress for the job as it will only be created if keycloakx is deployed as part of Renku.
This ensures the correct value is used if an external keycloak instance is used.
This ensure that the correct url is usd if using an external keycloak instance.
The work is twofold: - Use dedicated files for related policies - Use the specialized labels to establish connection The latter means that if new pods are added, they can simply adopt the proper label such as "renku.io/database-access" and they will directly have the proper access to the resource they need without having to add a new policy.
This will be removed once custom labels can be added to the controller manager pod.
Modernized from the original.
leafty
left a comment
leafty
left a comment
There was a problem hiding this comment.
Note: the deployment relabeling means that updating an existing renku deployment will fail as the spec.selector field is immutable.
This is a potential blocker: any operator applying the helm update or relying on gitops (e.g. flux) would see the upgrade fail as the changes to the deployments and stateful sets would be rejected.
There needs to be admin notes detailing the upgrade procedure (deleting workloads just before the update?).
Co-authored-by: Tasko Olevski <16360283+olevski@users.noreply.github.com>
Co-authored-by: Tasko Olevski <16360283+olevski@users.noreply.github.com>
Co-authored-by: Tasko Olevski <16360283+olevski@users.noreply.github.com>
Only deployment would be impacted in this case. While there are StatefulSets deployed as part of the helm chart, these are all externals and not impacted by the changes done in this patch. An update to the documentation in that direction is planned. |
Co-authored-by: Tasko Olevski <16360283+olevski@users.noreply.github.com>
Co-authored-by: Tasko Olevski <16360283+olevski@users.noreply.github.com>
And also add them to external dependencies deployed: - Keycloack - PostgreSQL - Redis - Solr
Even if the value is going to be the same, it's the proper way to generate it.
Make use of templates for lighter files and easier changes.
| registry: harbor.renkulab.io | ||
| repository: bitnami-mirror/redis | ||
| solr: | ||
| commonLabels: |
There was a problem hiding this comment.
Some of them can be a bit invasive and require deletion before upgrading due to changes to the generated manifests (until now only Renku's own deployments were affected).
This can be alleviated by using more fine-grained configuration options that target only the pod's labels so only a recreation would be done AFAICT.
What do you guys prefer ?
This will avoid pre-update deletion requirements
This allows admins to disable/enabled hardened mode. The main difference is that it changes the default deny policy from ingress only (mode until now) to ingress and egress (new default mode).
They need to be able to access outside in order to work properly.
This branch has not been deployed
4 participants
Describe your changes
This PR's goal is to tighten the network policies to make Renku safer to run.
The TLDR: deny all by default
Until now, only the ingress part was denied. This PR also closes the egress.
This work triggered some side effects that have brought the following changes:
Cluster admins deploying renku will need to provide the ingress rules for the ingress controller.
Note: the deployment relabeling means that updating an existing renku deployment will fail as the
spec.selectorfield is immutable.One option is, once the refactor has been approved, to add back the labels used for the original selector.
/deploy