Skip to content

Common issues and best practices in the Supportability Review data collection

Article Number: 000022303

Environment

  • SUSE Rancher v2.11+
  • Supportability Review App

Situation

  • Supportability Reviews (SR) are remote engagements in which a SUSE Technical Specialist reviews your Rancher deployment for a supportable system configuration and compliance with current recommended practices, highlighting any potential operational or supportability concerns. It involves two primary steps: data collection and data analysis.
  • Below are a few common issues and best practices while collecting data with the Supportability Review App.

Resolution

A) Security policy issues:

If your clusters use any security tools, review the required configurations:

  1. Pod Security Admission/Policies

  2. Sonobuoy pods require privileged access

  3. Collection pods need access to node information.

  4. If SR data collections fail due to the PSA error below, then exempt 'sr-operator-system' and 'sonobouy' namespace from the cluster. See the document here for more information on exempting the namespace.

    warnings.go:70] would violate PodSecurity "restricted:v1.31": allowPrivilegeEscalation != false (container "kube-sonobuoy" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "kube-sonobuoy" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "kube-sonobuoy" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "kube-sonobuoy" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
    2. Network Policies

  5. Allow egress traffic for collection pods

  6. Allow communication between Sonobuoy aggregator and collection pods

  7. Kyverno Policies

  8. Must exclude sonobuoy namespace from restrictive policies

  9. If using Kyverno, add this exclusion to your policies:

    exclude:
  any:
  - resources:
      namespaces:
      - sonobuoy
    4. Image Pull Policies

  10. Verify allowed registries in your security policies

  11. Configure image pull secrets if required

B) Permission issues:

  1. Rancher Access

  2. Bearer token must be generated by cluster owner (not a member)

  3. Token requires full access to target clusters
  4. Token should not be cluster-scoped, instead having full access
  5. How to generate a token

  6. Script Requirements

  7. Docker installed and running (or nerdctl/podman)

  8. User must be root or in the docker group

  9. Downstream Clusters must be Active

  10. Please ensure that your downstream clusters are listed as Active in Rancher

  11. Any cluster in an Updating state or not active will NOT have data collected for review

  12. SELinux

  13. Please use export ENABLE_PRIVILEGED="true", if SELinux is enabled.

C) Common Error messages:

  1. Permission Issues 

Error: pods is forbidden: User cannot list resource "pods"
Solution: Ensure bearer token is generated by a cluster owner, not member
2. Cluster Access Issues 

Info: No of clusters detected: X (less than expected)
Solution: Check if bearer token has access to all intended clusters
3. Node Tolerations
If the collection fails due to node taints, apply the toleration below:

     tolerations:
       - operator: Exists  # This will ignore all taints