https://github.com/kubernetes-sigs/security-profiles-operator/blob/main/installation-usage.md#install-operator

ODF policy status is currently tracking operator availabilty not the storage cluster and storage classes which are more important to know about

https://cloud.redhat.com/blog/viewing-cluster-alerts-warnings-or-recommendations-in-an-aggregated-view-with-red-hat-advanced-cluster-management-observability

We might document to add this:
https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.4/html/applications/managing-applications#using-custom-CA-certificates-for-secure-HTTPS-connection

https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.4/html/applications/managing-applications#git-SSH-connection

The latest RHACS operator recommends the rhacs-operator namespace to install the operator.

RHACS Central policy and RHACS Secured Cluster Policy should install operator in the rhacs-operator

These policies require two more templates.

1. Create rhacs-operator namespace.
2. Create rhacs-operator OperatorGroup.

If this issue is approved, I can create a PR for these policies.

go to the examples table here
https://github.com/stolostron/policy-collection/tree/main/stable

go to the Kyverno Generate Network Policies row:
See the Policy to install Kyverno.

The link returns 404

requested by the field

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

https://docs.openshift.com/container-platform/4.7/post_installation_configuration/cluster-tasks.html#informational-resources_post-install-cluster-tasks

Most policies in the collection are using remediationAction: inform, so policies are not 'enforced' out of the box.

Regarding Gatekeeper, it makes sense to enforce the creation of the ConstraintTemplate and Constraint objects when deploying a policy that relies on Gatekeeper. But, it would be more 'safe' to add enforcementAction: dryrun to the Gatekeeper's Constraint object definition. So the constraint is deployed, but it does not deny the creation of objects that violate the OPA policy.

For example, the next policy denies the creation of pods with <image-name>:latest image references as soon as its deployed. While this policy (from a 3rd party repository) is doing the same thing without enforcing the admission controller (since it has enforcementAction: dryrun defined in the Constraint object). This way, the policy monitors violations that Gatekeeper triggers, but it does not disallow the creation of objects.

Policy users can choose to remove enforcementAction: dryrun from the policy definition if they'd like the policy to be enforced in their environment.

I am getting the following error across multiple clusters that indicate Kyverno isn't actually getting installed from the policy-install-kyverno-prod-ns template:

violation - customresourcedefinitions not found: [policyreports.wgpolicyk8s.io] missing; violation - couldn't find mapping resource with kind Application, please check if you have CRD deployed; notification - subscriptions [kyverno-subscription-1] in namespace kyverno found as specified, therefore this Object template is compliant; violation - couldn't find mapping resource with kind PlacementRule, please check if you have CRD deployed; violation - couldn't find mapping resource with kind Channel, please check if you have CRD deployed

I can confirm there is nothing created in the kyverno or kyverno-channel namespaces

A number of the policies in the "stable" collection depend on CRDs created by the Compliance Operator:

• ScanSettingBinding
• ComplianceSuite
• ComplianceCheckResult
  A number of policies depend on a hardcoded namespace named: openshift-compliance

The CRDs above are created by the Compliance Operator, yet there is no mention in the documentation that the operator needs to be installed. Please update the documentation to include the requirement.

e.g. MustNotHave

 apiVersion: v1
 kind: Namespace
 metadata:
 spec:
 status:
   phase: Terminating

Example is here:
https://github.com/ch-stark/setupapplicationset-for-policies

in 2.3,2.4 we introducted Templating. https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.4/html/governance/governance#support-templates-in-config-policies
This issue is about providing more examples

https://github.com/openshift/managed-upgrade-operator
it is used by customers to better manage their upgrades and can work together with our upgrade policy, maybe upgrade PolicySet

This example is based on two parts

• label nodes
• use of https://docs.openshift.com/container-platform/4.9/nodes/scheduling/nodes-scheduler-node-selectors.html

When deploying the policyset openshift-hardening the remove kubeadmin policy is incorrectly reporting the status when enabled in inform mode. This is because it is missing the apiVersion field.

Issue first detected on ACM2.6.1/OCP4.11.2

maybe also to tune ArgoCD together.
some ideas can be found here:
https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.6/html-single/troubleshooting/index#troubleshooting-standalone-subscription-memory

this repository looks good:
https://github.com/raspbernetes/k8s-security-policies/tree/master/policies/

it contains rego-files to implement CIS

https://github.com/redhat-cop/rego-policies containes examples we might be use/reference in PolicyGenerator

ArgoCD gets more and more attention and we can perfectly work with ArgoCD.
See some blog we are working https://github.com/ch-stark/argocdpoliciesblog/blob/main/blog.md
we need to document how to deploy the PolicyCollectionRepository (example in the blog)
We also have some Policies which deploy a Helm-Chart in AppSub style and we should have examples for ArgoCd.

With the latest ocm release you can delete resources when policies are removed (unique to ConfigurationPolicy of course). If the delete gets stuck on a finalizer, the ConfigurationPolicy goes into a terminating state and waits for the resources to be deleted. Create a policy to alert when this has happened -- the root policy will be gone.

@ycao56
Please check this PR and merge
#86
The changes reflect the upgraded version of IShield operator (0.1.4)

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
  generation: 2
  labels:
    app: search-prod
    app.kubernetes.io/managed-by: Helm
    chart: search-prod-2.5.0
    component: search-operator
    heritage: Helm
    installer.name: multiclusterhub
    installer.namespace: open-cluster-management
    release: search-prod-12d02
    manager: multicluster-operators-subscription
  name: search-operator
  namespace: open-cluster-management
  ownerReferences:
  - apiVersion: apps.open-cluster-management.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: HelmRelease
    name: search-prod-12d02
    uid: 86d3d8b7-ddab-4bf7-98a2-2909bb396053
  resourceVersion: "123881"
  uid: 8dcb24b9-9d43-44f4-b693-f8aca481d65c
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      name: search-operator
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: search-prod
        chart: search-prod-2.5.0
        heritage: Helm
        name: search-operator
        ocm-antiaffinity-selector: searchoperator
        release: search-prod-12d02
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: ocm-antiaffinity-selector
                  operator: In
                  values:
                  - searchoperator
              topologyKey: topology.kubernetes.io/zone
            weight: 70
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: ocm-antiaffinity-selector
                  operator: In
                  values:
                  - searchoperator
              topologyKey: kubernetes.io/hostname
            weight: 35
      containers:
      - args:
        - --enable-leader-election
        command:
        - /manager
        env:
        - name: RELEASE_NAME
          value: search-prod-12d02
        - name: WATCH_NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        - name: POD_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.name
        - name: OPERATOR_NAME
          value: search-operator
        - name: SEARCH_COLLECTOR_IMAGE_NAME
          value: quay.io/stolostron/search-collector@sha256:63c5dde252a968917381ba00436459d4ccf991937ac2d3f756de61f8245a497d
        - name: DEPLOY_REDISGRAPH
          value: "true"
        image: quay.io/stolostron/search-operator@sha256:7c07841572b19eec94f0339166f23a74da664dfa559c4cb005e8c713c6eaf73c
        imagePullPolicy: IfNotPresent
        name: search-operator
        resources:
          limits:
            memory: 256Mi
          requests:
            cpu: 1m
            memory: 32Mi
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      imagePullSecrets:
      - name: multiclusterhub-operator-pull-secret
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext:
        runAsNonRoot: true
      serviceAccount: search-operator
      serviceAccountName: search-operator
      terminationGracePeriodSeconds: 30
      tolerations:
      - effect: NoSchedule
        key: node-role.kubernetes.io/infra
        operator: Exists

oc set env deploy search-operator DEPLOY_REDISGRAPH="true" -n open-cluster-management

requested from the field

• we need Secrets which have to be templatized

Console plugin for ODF still requires manual enablement after the policy has been enforced. This should be auto.

Policies only on the Hub is e.g. All Policies for ApplicationSets, ACS-Central, Subscription-Admin, Managed-ClusterSet-Bindings e.g.

There might be other scenarios, e.g. a Policy must be only applied to one Managed-Cluster or a Policy must not be applied on the Hub-Cluster.

apiVersion: cluster.open-cluster-management.io/v1beta1
kind: ManagedClusterSetBinding
metadata:
namespace: policies
name: default
spec:
clusterSet: default

After running the input-acm-observabilty policies, multiclusterhub-operator-pull-secret is missing. According to the ACM installation guide this is required by the obervability service.

https://access.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.5/html/observability/observing-environments-intro#prerequisites-observability

Placement works already but the Policies use PlacementRules.

Hi guys,
So I forked this repo to an disconnected environment and followed the procedure step by step but could not implement the policies using gitops.
The only information I have is the logs from the klusterlet-addon-appmgr pod:
Exit reconciling subscription.
The policies are in a private gitLab instance.

we have below requirement which we wanted to check :

Lets say user has 3 namespaces in managed cluster A, B ,C , he wants a USERA to access and view only project a from ACM console or Grafana console

similarly he wants his other user lets say USERB to access and view only project b from ACM console or Grafana console

He should see the resources of project A with USERA in ACM console as well as in grafana console

As of now we can restrict user in cluster level by using the below comnands :

oc create clusterrolebinding userA --clusterrole=open-cluster-management:view:devcluster --user=userA
oc create rolebinding userA -n devcluster --clusterrole=devclusterview --user=userA

by this commands , userA can see all namespaces in devcluster , but we want to restrict userA to see only project A.

is that possible ?
Can someone please guide us

Hi,

I was trying to use the native syntax of OPA/Gatekeeper, but it seems like there Gatekeeper of Redhat Marketplace is not the same as community one:

Anyway, this is the policy, which does not take effect unfortunetely:

apiVersion: templates.gatekeeper.sh/v1beta1
kind: ConstraintTemplate
metadata:
  name: preventdeletingallnamespaces
spec:
  crd:
    spec:
      names:
        kind: PreventDeletingAllNamespaces
      validation:
        # Schema for the `PreventDeletingAllNamespaces` CR
        # This CR will be used to enforce the constraint
        openAPIV3Schema:
          properties:
            apiVersion:
              type: string
            kind:
              type: string
            metadata:
              type: object
            spec:
              type: object
  # Parameters for the OPA policy
  targets:
    - target: admission.k8s.gatekeeper.sh
      rego: |
        package preventdeletingallnamespaces

        # import data.kubernetes.namespaces
        # import data.lib.openshift.namespaces
        # Deny deletion if the namespace doesn't have the required annotation
        violation[msg] {
            input.request.operation == "DELETE"
            input.request.kind.kind == "Namespace"
            # not namespace_has_allow_delete_annotation(input.request.namespace)
            msg := sprintf("Deletion of namespace '%v' is not allowed as it is not annotated with allow-delete=true", [input.request.namespace])
        }

        # Check if the namespace has the required annotation
        namespace_has_allow_delete_annotation(namespace) {
            namespaces[namespace].metadata.annotations["allow-delete"] == "true"
        }

---
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: PreventDeletingAllNamespaces
metadata:
  name: preventdeletingallnamespaces
spec: {}

testing it :

oc create ns test-hello
oc delete ns test-hello
# It was not denied !?

Could you please provide a working policy with the same purpose?

We updated the ACM policy policy-integrity-shield to include the changes in IShield CRDs as well as references to updated IShield images.
@ycao56
Could you review this PR and merge ?
#71
Thank you

can you please add a network policy like

    - complianceType: "musthave"
      objectDefinition:
        kind: NetworkPolicy
        apiVersion: networking.k8s.io/v1
        metadata:
          namespace: default
          name: deny-from-other-namespaces
        spec:
          podSelector:
            matchLabels:
          ingress:
          - from:
            - podSelector: {} # accept ingress from all pods within this namespace only

We received feedback that it would be nice to have this!

Started here:

https://github.com/ch-stark/governance-best-practises-for-apps

Purpose of this PolicySet should be that it is working generic for all Kubernetes-Clusters

Policy will be updated:

• check for namespaces in terminating
• missing labels
• pods in pending state

Hi
it may be good to change collection method as EBPF. KernelModule is deprecated

https://docs.openshift.com/acs/3.74/release_notes/374-release-notes.html#kernel-collection-module

Added 20 March 2023

Currently, secured clusters can specify three options of collection methods for runtime events: eBPF (selected by default), kernel module, or no collection. Kernel module as a collection method is deprecated in the RHACS version 3.74 release and is planned for removal in the RHACS version 4.1 release.

Solution describing this can be found here:

https://access.redhat.com/solutions/6699251

would be nice to have the solution point to a concrete example

This link is very useful for showing different behaviour on merge/patch:
https://github.com/stolostron/governance-policy-framework/blob/main/doc/configuration-policy/README.md#merge-patch
we could link this together with our documentation

In https://github.com/stolostron/policy-collection/blob/ad66e6b90a83f6f98d044596b42bc0c436d4a879/community/SC-System-and-Communications-Protection/policy-remove-kubeadmin.yaml

We have a:

          namespaceSelector:
            exclude:
              - kube-*
            include:
              - default

And at the same time want that the kubeadmin Secret in kube-system is removed. But kube-system is excluded through the selector.

During manual failover when working with ODF the following object has been created.
This is to investigate if a Policy should be created

apiVersion: ramendr.openshift.io/v1alpha1
kind: DRPlacementControl
metadata:
  name: pacman-placement-1-drpc
  namespace: pacman
  finalizers:
    - drpc.ramendr.openshift.io/finalizer
  labels:
    app: pacman
    cluster.open-cluster-management.io/backup: resource
spec:
  action: Failover
  drPolicyRef:
    name: ocp4perf1-ocp4perf2-2m
  failoverCluster: ocp4perf2
  placementRef:
    kind: PlacementRule
    name: pacman-placement-1
    namespace: pacman
  preferredCluster: ocp4perf1
  pvcSelector: {}

Author a blog to outline how ACM's configuration management capability can be used to implement policy based governance

As per the title it would be great to keep this policy current with the latest GA release

example is here:
https://github.com/ch-stark/maptoseveralstandards/blob/main/config/input/ansible/automation-hub.yaml

question is should this be provided as policy or just as input for PolicyGenerator?

e.g like below it helps to use PolicyGenerator more easily:

mkdir -p ${HOME}/.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator

curl -L \
  -o ${HOME}/.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator/PolicyGenerator \
  https://github.com/stolostron/policy-generator-plugin/releases/download/v1.8.0/linux-amd64-PolicyGenerator
chmod +x ${HOME}/.config/kustomize/plugin/policy.open-cluster-management.io/v1/policygenerator/PolicyGenerator

curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh"  | bash


sudo chmod a+x kustomize /usr/local/sbin
sudo cp kustomize /usr/local/sbin

https://www.redhat.com/en/openshift-sandboxed-containers
https://rcarrata.com/openshift/sandbox-containers/

Issues have been reported, policy will be reviewed, tested and updated