-
Notifications
You must be signed in to change notification settings - Fork 197
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
test(kube-bench): Add integration test for kube-bench command #98
Conversation
Codecov Report
@@ Coverage Diff @@
## master #98 +/- ##
==========================================
- Coverage 11.35% 11.30% -0.05%
==========================================
Files 27 27
Lines 1295 1300 +5
==========================================
Hits 147 147
- Misses 1141 1146 +5
Partials 7 7
Continue to review full report at Codecov.
|
728e9b0
to
2934736
Compare
Signed-off-by: Daniel Pacak <pacak.daniel@gmail.com>
2934736
to
34ac151
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.
I don't have any experience with ginkgo so I am taking your word for it :-)
Couple of small comments / suggestions but I am happy
Labels: labels.Set{ | ||
"app.kubernetes.io/name": "starboard-cli", | ||
kube.LabelResourceKind: string(kube.KindNode), | ||
kube.LabelResourceName: node.Name, |
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 wonder if in addition we should add a label to indicate that it's a kube-bench job? something like "starboard-app": "kube-bench"
maybe? (also for pod-spec and for other kinds of tool)
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.
Yes. That's a very good point. I'll take it as a separate issue to review the labels to identify scan job and the underlying tools.
I think it's less relevant for Starboard CLI, but the Operator has no clue which scanner we're running in the starboard namespace.
// TODO run by the BeforeEach callback fails when it attempts to create Kubernetes objects in the | ||
// TODO starboard namespace that is being terminated. | ||
// | ||
// TODO Maybe the cleanup command should block and wait unit the namespace is terminated? |
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 think this might be a good idea for users too. I ran into this recently - cleanup followed quickly by init failed. It was pretty obvious why, but waiting for the namespace to be gone would prevent it from being a problem at all.
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.
Created a task to follow up #99
This PR:
/cc @krol3
Signed-off-by: Daniel Pacak pacak.daniel@gmail.com