Cluster hardening app via ArgoCD using sync-waves between/across apps #39
Conversation
…e operator and existing scan profiles. This app is loaded first by Argo based on leveraging sync-wave annotation in the values-hub.yaml
…f in spec: and then ran linter against updated content
…an and then for each complianceremediation generated it changes default state of spec.apply false to spec.apply true and then merges that back into cluster to take effect
… instead use vp container image that has tools preloaded
….apply set to True
| --- | ||
| # ClusterRole with permissions to manage compliance resources | ||
| apiVersion: rbac.authorization.k8s.io/v1 | ||
| kind: ClusterRole |
There was a problem hiding this comment.
Does this need to be a clusterRole? If all the objects you're touching are in openshift-compliance it might not need to be.
There was a problem hiding this comment.
It may not need to be. The fact I set it that way shows my ignorance of remediation controller within compliance operator. I did set all elements to be openshift-compliance namespace focused but don't know if namespace scoped auth is sufficient for something that can reboot nodes during remediation
| name: {{ .Values.compliance.scanSettingBinding.name }} | ||
| namespace: openshift-compliance | ||
| annotations: | ||
| argocd.argoproj.io/sync-wave: '-10' |
There was a problem hiding this comment.
We generally only use sync-waves when not using them leads to errors or other problems with deployments. I am very unfamiliar with the compliance operator, so they may indeed be necessary. But if they aren't it's better not to have them. (As discussed we definitely need them in clustergroup, though).
There was a problem hiding this comment.
This was me trying to ensure that the scan stuff was there before the results viewer and remediation updaters were available
|
So compliance scans do run and remediations are identified currently |
Identifies what things look like with current PR deployed.
Scans have run, remediations are identified.
My reemdiation-job will eventually timeout due to bash script failing to get a proper env for a KUBECONFIG to use to execute the kubectl commands in the script
|
…cussion with VP team and no need to do that in other examples
|
Updated PR with removal of env for KUBECONFIG and now imperative-container executes the bash script in remediation job and can use oc/kubectl commands |
…for remediation-job
All of the complianceremediation CRs have been updated by the remediation job to have spec:apply set to true.
However all of the status is still Pending after the patch
|
…ussion with compliance operator team. It should get generated at runtime
Seems like I uncovered an edge case where automated remediation just fails silently on ROSA clusters.
Things work as expected on a non ROSA cluster.
Spun up aws 4.18.22 with clusterbot
Remediations run automatically with ScanSetting and ScanSettingBinding as defined (I did remove the annotation on the ScanSettingBinding)
There are a lot of complianceremediations run but all either show Applied or Missing Dependencies
Overall compliancescans show RESULT as NON-COMPLIANT. Wondering if there is a way to automatically trigger another scan after remediations?
|
…m ComplianceCheckResults in Compliance Operator
ghost
requested a review
from
|
Since 15 of these commits were attempts to figure out why auto remediation wasn't working I am going to close this PR, rebase and only add the 5 files required along with updates to values-hub.yaml |
ghost
closed this
2 participants
This deploys scansetting and scansettingbinding for profile defined in values.yaml to run in a sync-wave before other layer-0,1, or 2 apps.