GEP-0063: Diki Extension#64
Conversation
gardener-prow
Bot
added
area/security
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
gardener-prow
Bot
added
size/XL
vpnachev
left a comment
vpnachev
left a comment
There was a problem hiding this comment.
Thanks for the proposal, very well structured!
My impression is that it is covering quite some diki-operator specifics like the CRDs and how the operator is running the scans, but this proposal tries to focus on the extension. Should the diki-operator become a detailed topic of this GEP, or does it need a dedicated one, or keep its development without a GEP (and try to clean up this extension from operator specific topics)?
| - [diki-operator](#diki-operator) | ||
| - [diki-admission-controller](#diki-admission-controller) | ||
| - [diki-run](#diki-run) | ||
| - [Architecture](#architecture) |
There was a problem hiding this comment.
Looks like there is no paragraph named Architecture
| burdens and makes compliance accessible to all shoot users through familiar | ||
| Kubernetes resource semantics. | ||
|
|
||
| ### Goals |
There was a problem hiding this comment.
I think it will be of common interest to scan not only end-user shoot clusters, but also Seeds, Gardens and probably self-hosted shoots. Could you extend the proposal so that the extension covers also these use cases?
| out of scope. | ||
| - Integration with the Gardener Dashboard. | ||
|
|
||
|
|
There was a problem hiding this comment.
You can remove one of the two empty lines here.
|
|
||
| - Introduce `gardener-extension-diki` as a Gardener extension | ||
| that deploys the `diki-operator` into shoot control planes on seeds. | ||
| - Allow shoot users to run on-demand compliance scans by creating a |
There was a problem hiding this comment.
Do you envision to support configuring the scans and report outputs via the Gardener API? Admins in the shoot clusters can interfere with the diki CRDs and misconfigure them, Gardener users may want to define only once the rulesets for all of their shoots.
| `ComplianceScan` or `ScheduledComplianceScan` resources. The `diki-operator` in | ||
| the seed watches these resources (via the shoot API server) and orchestrates | ||
| scan execution by creating `diki-run` Jobs in the shoot's control-plane namespace. | ||
| The `diki-run` Pod writes summary reports back to the `ComplianceScan` status |
There was a problem hiding this comment.
Will diki scan only the data plane? Considering it is running in the control plane and have access to the control plane components, will it be an option for the end-users to get reports about their control plane compliance posture?
| | Phase | Behaviour | | ||
| |-------|-----------| | ||
| | Reconcile | Deploys `diki-operator` and diki-admission-controller to the shoot namespace on the seed. Creates a `ManagedResource` with CRDs, RBAC, and supporting resources for the shoot cluster. Waits for `ManagedResource` health before marking the `Extension` as reconciled. | | ||
| | Delete | Deletes the `diki-operator` deployment and the `ManagedResource`. Waits for all managed objects to be removed from the shoot cluster before completing. | |
There was a problem hiding this comment.
Will it delete also the custom resource definitions for the ComplianceScan, ScheduledComplianceScan, ReportOutput, etc.?
| this ruleset require access to the garden cluster (e.g., to inspect Shoot and | ||
| CloudProfile resources). Supporting this ruleset will require a mechanism for | ||
| the diki-run Job to obtain scoped, read-only garden cluster credentials — | ||
| a design that is deferred to a future iteration. |
There was a problem hiding this comment.
There is already a concept how extensions to get access to the Gardener API, however I am not sure diki really need it, both the shoot and cloudprofile specs are available in the extensions.gardener.cloud/v1alpha1.Cluster resource. The diki-extension (or the operator) can read the resource and extract the Shoot and the CloudProfile out of it.
| a design that is deferred to a future iteration. | ||
| - Version management: Expose available Diki versions and ruleset versions | ||
| to users via the API. | ||
| - Persistent storage backends: Add support for PostgreSQL, OpenSearch, and |
There was a problem hiding this comment.
Do you envision an option for non-solution specific output? Such solution should satisfy the need of those users that are using not widely adopted storage products.
| - Dashboard integration: Integrate with the Gardener Dashboard to | ||
| visualize compliance scan summary results, and allow users to trigger | ||
| scans from the UI. | ||
| - Report access proxy: Provide an authenticated proxy or server for |
There was a problem hiding this comment.
Is this scoped only to reports stored within the Seed or Gardener installation, e.g. managed storage?
|
|
||
| An alternative architecture would deploy the compliance CRDs | ||
| (`ComplianceScan`, `ReportOutput`, `ScheduledComplianceScan`) as namespaced | ||
| resources in the garden cluster, while running the compliance operator in a |
There was a problem hiding this comment.
I would still find it valuable if I can configure some scan jobs centrally and rely they are applied to all of my shoots or keep the configuration together with the shoot spec.
2 participants
/area security
/area compliance
/kind enhancement
Diki Extension(gardener extension that would deploy the diki-operator)