-
Notifications
You must be signed in to change notification settings - Fork 255
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
Add an example of InstallPlanApprover #256
Comments
This worked for me: - objectDefinition:
apiVersion: policy.open-cluster-management.io/v1
kind: ConfigurationPolicy
metadata:
name: managed-cluster-security-operator-sub
spec:
remediationAction: inform
severity: high
object-templates:
- complianceType: musthave
objectDefinition:
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: rhacs-operator
namespace: rhacs-operator
spec:
channel: latest
installPlanApproval: Automatic
name: rhacs-operator
source: redhat-operators
sourceNamespace: openshift-marketplace
# With the following object we aprove the instalation of the operator
- complianceType: musthave
objectDefinition:
apiVersion: operators.coreos.com/v1alpha1
kind: InstallPlan
metadata:
# The enforcement fails at first because the name is "<no value>" but then it applies correctly
name: '{{ (lookup "operators.coreos.com/v1alpha1" "Subscription" "rhacs-operator" "rhacs-operator").status.installPlanRef.name }}'
namespace: rhacs-operator
spec:
approved: true |
The following enhancement is being worked on too. https://github.com/open-cluster-management-io/enhancements/tree/main/enhancements/sig-policy/89-operator-policy-kind#operatorpolicy-syntax |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
when manually updating Operators where is currently a known aspect of the current implementation that installation and updates are treated differently in the internal logic
The following workaround can be used (in Gitops-Scenarios).
https://github.com/redhat-cop/gitops-catalog/tree/main/installplan-approver
This example can be further enhanced or reimplement e.g. by Kyverno to check only one specific operator, even if they are in the same namespace
Some ideas:
if you can write a match rule to identify the approval resource, I think you could then mutate it to approve it.
https://kyverno.io/docs/writing-policies/mutate/
Some work done:
https://github.com/mvazquezc/telco-operations/blob/kyverno/rhacm/kyverno/assets/autoapprove-installplans-in-namespace.yaml
The text was updated successfully, but these errors were encountered: