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

Security and compliance validation #2376

Closed
6 tasks
Akatuoro opened this issue Mar 7, 2023 · 1 comment · Fixed by #2435 or #2531
Closed
6 tasks

Security and compliance validation #2376

Akatuoro opened this issue Mar 7, 2023 · 1 comment · Fixed by #2435 or #2531
Labels
kind/feature Categorizes issue or PR as related to a new feature.

Comments

@Akatuoro
Copy link
Contributor

Akatuoro commented Mar 7, 2023

Description

Add tooling to visualize insecure or non-compliant configurations and workloads. The validation needs to be possible for the whole cluster and can also be shown as warning when creating resources. Since security and compliance needs differ for applications, the rules need to be configurable.

Reasons

Keeping the Kyma runtime cluster secure and compliant is an important but sometimes not easy activity. Even if Kyma is shipping the cluster secure by default, the responsibility to keep it secure is on the user side. On application side, there may also be non-compliant or insecure configuration changes, e.g. when new features are introduced.
Validation tooling can help visualize and give a report on whether the cluster is secure and whether it complies with specific standards.

Tasks

  • This is a core functionality that needs to have in mind performance and try not to choke the API server.
    • We evaluate the use of javascript workers, to allow background work
    • We evaluate the use of a queue, that allows the control of requests. The concurrency will be configurable allowing for at least 2 options: aggressive/active scan or background scan
    • It's acceptable that between scans the resource can change and we don't capture that. There is no need for a watch the resource approach
    • Evaluate the possibility of using an in-memory DB that can be used as a cache and also as a source for the workers.
    • Various workers ( that can run different rulesets ) can run at different intervals.
@valentinvieriu valentinvieriu added the kind/feature Categorizes issue or PR as related to a new feature. label Mar 15, 2023
@mrCherry97 mrCherry97 linked a pull request Apr 14, 2023 that will close this issue
@mrCherry97 mrCherry97 reopened this Apr 27, 2023
@kyma-bot
Copy link
Contributor

This issue or PR has been automatically marked as stale due to the lack of recent activity.
Thank you for your contributions.

This bot triages issues and PRs according to the following rules:

  • After 60d of inactivity, lifecycle/stale is applied
  • After 7d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

  • Mark this issue or PR as fresh with /remove-lifecycle stale
  • Close this issue or PR with /close

If you think that I work incorrectly, kindly raise an issue with the problem.

/lifecycle stale

@kyma-bot kyma-bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 27, 2023
@mrCherry97 mrCherry97 removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants