ROX-30241: Updates for vm scanning#106074
ROX-30241: Updates for vm scanning#106074kcarmichael08 wants to merge 1 commit intoopenshift:rhacs-docs-mainfrom
Conversation
openshift-ci-robot
added
the
jira/valid-reference
|
@kcarmichael08: This pull request references ROX-30241 which is a valid jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
@kcarmichael08: This pull request references ROX-30241 which is a valid jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
openshift-ci
bot
added
the
size/L
kcarmichael08
force-pushed
the
ROX-30241-virt
branch
3 times, most recently
from
f537670 to
4e41c7a
Compare
|
@kcarmichael08: This pull request references ROX-30241 which is a valid jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
@kcarmichael08: This pull request references ROX-30241 which is a valid jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
kcarmichael08
force-pushed
the
ROX-30241-virt
branch
from
4e41c7a to
caada79
Compare
openshift-ci
bot
added
size/XL
|
@kcarmichael08: This pull request references ROX-30241 which is a valid jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
kcarmichael08
force-pushed
the
ROX-30241-virt
branch
from
caada79 to
b6e6110
Compare
|
@kcarmichael08: This pull request references ROX-30241 which is a valid jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
@kcarmichael08: This pull request references ROX-30241 which is a valid jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
@kcarmichael08: This pull request references ROX-30241 which is a valid jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
@kcarmichael08: This pull request references ROX-30241 which is a valid jira issue. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
kcarmichael08
force-pushed
the
ROX-30241-virt
branch
3 times, most recently
from
6288072 to
e67e1e3
Compare
| * The Sensor deployment on your secured clusters | ||
| * Compliance container in the collector daemonset | ||
| .. Edit the ***?yaml file?*** to contain the following information: | ||
| //Need the filenames or some additional information here about where the environment variable would be located |
There was a problem hiding this comment.
Can someone tell me the files that the user needs to specifically edit? Is it the Central and secured cluster CRs? What file needs to be edited in the "compliance container in the Collector daemonset"?
There was a problem hiding this comment.
This is about adding environment variables to the central pod - central container, sensor pod - sensor container, and collector pod - compliance container. I see there's already documentation on env vars here.
I am not sure what's the right way of presenting this to users. When I install manually using helm I use this:
--set customize.envVars.ROX_VIRTUAL_MACHINES=true
There was a problem hiding this comment.
By the way, I think when the original text mentions editing a file, it's the yaml manifest of an already running ACS (kubectl -n stackrox edit deployment central). I doubt that is what we need in this context.
kcarmichael08
force-pushed
the
ROX-30241-virt
branch
from
e67e1e3 to
814e60b
Compare
|
@kcarmichael08: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
| * The Sensor deployment on your secured clusters | ||
| * Compliance container in the collector daemonset | ||
| .. Edit the ***?yaml file?*** to contain the following information: | ||
| //Need the filenames or some additional information here about where the environment variable would be located |
There was a problem hiding this comment.
This is about adding environment variables to the central pod - central container, sensor pod - sensor container, and collector pod - compliance container. I see there's already documentation on env vars here.
I am not sure what's the right way of presenting this to users. When I install manually using helm I use this:
--set customize.envVars.ROX_VIRTUAL_MACHINES=true
| * The Sensor deployment on your secured clusters | ||
| * Compliance container in the collector daemonset | ||
| .. Edit the ***?yaml file?*** to contain the following information: | ||
| //Need the filenames or some additional information here about where the environment variable would be located |
There was a problem hiding this comment.
By the way, I think when the original text mentions editing a file, it's the yaml manifest of an already running ACS (kubectl -n stackrox edit deployment central). I doubt that is what we need in this context.
| . Optional: On the cluster where Central is installed, you can configure the following environment variables: | ||
| * ROX_VIRTUAL_MACHINES_VSOCK_PORT: Port for vsock connections. The default value is 818. | ||
| * ROX_VIRTUAL_MACHINES_VSOCK_CONN_MAX_SIZE_KB: Maximum connection size in KB. The default value is 16384. |
There was a problem hiding this comment.
These are low-level settings that would only come into play in rather exotic scenarios. I think they would be a good fit in an "advanced configuration" section or similar, if we have one.
In any case, a fix is needed: instead of central, these settings need to be applied to the collector pod (compliance container), in secured clusters, much like ROX_VIRTUAL_MACHINES=true
| $ kubectl patch hyperconverged kubevirt-hyperconverged -n openshift-cnv --type='merge' \ | ||
| --patch='{"spec":{"configuration":{"developerConfiguration":{"featureGates":["VSOCK"]}}}}' |
There was a problem hiding this comment.
This command seems not to work according to this user report. I have always used this myself:
cat << EOF | kubectl apply -f -
apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
name: kubevirt-hyperconverged
namespace: openshift-cnv
annotations:
kubevirt.kubevirt.io/jsonpatch: |-
[
{
"op":"add",
"path":"/spec/configuration/developerConfiguration/featureGates/-",
"value":"VSOCK"
}
]
spec: {}
EOFI asked AI for a kubectl patch equivalent, and it replied with this (unverified yet I just tried it and it works):
kubectl patch hyperconverged kubevirt-hyperconverged -n openshift-cnv --type=merge -p '
{
"metadata": {
"annotations": {
"kubevirt.kubevirt.io/jsonpatch": "[{\"op\":\"add\",\"path\":\"/spec/configuration/developerConfiguration/featureGates/-\",\"value\":\"VSOCK\"}]"
}
}
}'| $ kubectl patch hyperconverged kubevirt-hyperconverged -n openshift-cnv --type='merge' \ | ||
| --patch='{"spec":{"configuration":{"developerConfiguration":{"featureGates":["VSOCK"]}}}}' | ||
| ---- | ||
| * Use the following annotation: |
There was a problem hiding this comment.
Should we somehow highlight that this is an alternative to the previous step? If not using the provided kubectl patch command, the user can edit the hyperconverged CR by any means (e.g. in the openshift UI, via k9s) to add that annotation manually.
The key in this section, what actually triggers vsock being enabled, is the presence of the annotation. How it's added is only important to help the user get there. Perhaps we could first show how it's supposed to look (this part) and then one of the methods to achieve it (the kubectl patch command)
| * Only {op-system-base} packages indexed by DNF with valid repository links can be scanned. | ||
| * Scanning requires sudo privileges for `roxagent` to scan package databases. | ||
| * Only packages managed by Red Hat Package Manager (RPM) and DNF are detected. | ||
| * Network connectivity is required for repository-to-CPE mapping downloads. |
There was a problem hiding this comment.
@stehessel , @vikin91 , I was suggesting here to explain that we require internet connectivity, but I am not sure: do we serve this from sensor today, so that users can set --repo-cpe-url to a sensor endpoint and it will work?
| * Network connectivity is required for repository-to-CPE mapping downloads. | |
| * Internet connectivity is required for repository-to-CPE mapping downloads. |
| ** Verify the feature flag is enabled on all components. | ||
| ** Check Central logs for enrichment processing. | ||
| ** Ensure the VM has a valid {op-system-base} subscription. | ||
| ** Confirm repository-to-CPE mapping downloads are successful. |
There was a problem hiding this comment.
Do we think customers will know what this refers to, and how to check its success? IIUC the most obvious reason why this would fail is lack of connectivity to internet, and it would be visible in the logs: error updating mapping file
There was a problem hiding this comment.
The URL from where this file his downloaded can be configured via the --repo-cpe-url argument to roxagent. Not sure if that is relevant here or elsewhere!
| ** Ensure the VM has a valid {op-system-base} subscription. | ||
| ** Confirm repository-to-CPE mapping downloads are successful. | ||
| * If there is a network connectivity problem: | ||
| ** Verify the VM has internet access or connectivity to Sensor. |
There was a problem hiding this comment.
I guess this is related to the previous repository-to-CPE download. Let's double check (I asked experts in this comment) that sensor actually serves this file, otherwise we should remove the Sensor part.
| = Requirements for virtual machine scanning | ||
|
|
||
| [role="_abstract"] | ||
| To use {product-title} ({product-title-short}) to scan virtual machines (VMs), you must ensure that they meet specific requirements. |
There was a problem hiding this comment.
Since we're listing both k8s and VM requirements, we could change this:
| To use {product-title} ({product-title-short}) to scan virtual machines (VMs), you must ensure that they meet specific requirements. | |
| To use {product-title} ({product-title-short}) to scan virtual machines (VMs), you must ensure that the following requirements are met. |
| * VMs must have network access to download repository-to-Common Platform Enumeration (CPE) mappings. | ||
| * DNF must be installed. | ||
|
|
||
| For optimal performance, host VMs on metal nodes. |
There was a problem hiding this comment.
Hosting VMs on metal nodes increases the performance of the VM itself, but makes little difference in the context the ACS VM feature: roxagent will run faster, but the difference between metal and non-metal is in the order of tens of seconds, while the default scan interval is 4 hours.
At ACS level, performance naturally relates to the number of VMs that it can handle, and this is constrained by CPU resources of Scanner V4, not the VM itself. What matters is that index reports arrive eventually from each VM.
I think I would rather remove this since VM performance does not relate to ACS performance and it may lead to questions like "can I scan more VMs if they run in metal nodes?"
@vikin91 , @stehessel , @kylape views/objections?
4 participants
Version(s): 4.10
Issue: ROX-30241
Link to docs preview:
New sections:
https://106074--ocpdocs-pr.netlify.app/openshift-acs/latest/operating/examine-images-for-vulnerabilities.html#scanning-virtual-machines_examine-images-for-vulnerabilities
https://106074--ocpdocs-pr.netlify.app/openshift-acs/latest/operating/manage-vulnerabilities/common-vuln-management-tasks#viewing-view-vms-cves_vms
note to reviewers: Please focus on new sections. We had to fix some issues with modules/assemblies so that our files will pass new pre-migration checks that are being added to the repo in advance of our conversion to DITA and move to a new doc publishing program this year. These changes are included so that the PR will pass but do not affect the new material added to the docs.
Focus on:
Ignore changes in:
QE review:
Additional information: