Configuring IBM Cloud Pak foundational services

The IBM Cloud Pak foundational services operator creates the CommonService custom resource (CR) in the <foundational-services> namespace.

The custom resource has the services, cluster configurations, and hardware profile that you can set before or after you install foundational services.

You can access the CommonService custom resource by using the OpenShift Container Platform console or by using the command-line interface (CLI).

• To use the console, complete these steps:

  1. From the navigation pane, click Operators > Installed Operators.
  2. From the Project drop-down list, select <foundational-services>.
  3. Click IBM Cloud Pak foundational services.
  4. Select the CommonService tab. You can see the common-service custom resource instance.
  5. Click the common-service resource.
  6. Select the YAML tab.

• To use the CLI, run the following command:

oc edit CommonService common-service -n <your-foundational-services-namespace>

Parameters in the CommonService CR

The CommonService CR has some parameters that control the placement of the OperandRegistry and OperandConfig in various deployment topologies. For more information about the topologies, see Topologies that need the IBM NamespaceScope Operator.

• The servicesNamespace parameter determines the namespace in which the OperandRegistry and OperandConfig CRs are to be defined. The default is the same namespace in which the ibm-common-service-operator is deployed. The services that are shared across a tenant, such as the IM service, are also deployed in the servicesNamespace.

• The operatorNamespace parameter determines where the requested service operators (subscriptions) are to be deployed. The default is the same namespace in which the ibm-common-service-operator is deployed.

• The catalogName parameter is the foundational services operator catalog name. The default value is the spec.source parameter value from the ibm-common-service-operator subscription. A service operator subscription uses the parameter to refer to the correct catalog source.

• The catalogNamespace parameter is the foundational services operator catalog namespace. A service operator subscription uses the parameter to refer to the correct catalog namespace. The default value is the spec.sourceNamespace parameter value from the ibm-common-service-operator subscription.

Updating the custom resource

Set the following parameters by adding them to the CommonService custom resource. You can update these parameters before you create an OperandRequest instance or after you install the services. Add or modify the parameters and values in the spec section.

• Approval strategy
• Bring your own CA Certificate
• Licenses
• Hardware profile
• Storage class
• Services configuration
  • General settings
    • Federal Information Processing Standard (FIPS)
  • MongoDB settings
    • Storage class (ibm-im-mongodb-operator)
    • Changing the default values of the MongoDB username and password (ibm-im-mongodb-operator)
    • Configuring resources for MongoDB (ibm-im-mongodb-operator)
  • Authentication settings
    • Changing the default cpadmin username
    • Delegating authentication to OpenShift (ibm-im-operator)
      • Assigning the Cloud Pak administrator privileges to an OpenShift user
    • Adding custom OIDC claims
    • Disabling nonce
    • Adding description of the login options (ibm-idp-config-ui-operator)
    • Setting the preferred login options (ibm-im-operator)
    • Changing the OIDC issuer URL (ibm-im-operator)
    • Changing the provider issuer URL (ibm-im-operator)
    • Changing the cluster name (ibm-im-operator)
    • HA configuration
    • Sample ibm-im-operator operator section in the custom resource
    • Configuring resources for IM (ibm-im-operator)
  • License Service settings
    • Enable additional information in logs for troubleshooting purposes
    • Configure resources for License Service (ibm-licensing-operator)
  • MustGather settings
    • MustGather configuration settings
    • MustGather job settings
    • MustGather service settings
  • Certificate management service settings
    • Configuring resources for Certificate manager (ibm-cert-manager-operator)
    • certManagerCAInjector
    • certManagerController
    • certManagerWebhook
    • Leaf certificate refresh parameters
  • Common Web UI settings

Approval strategy

The approval strategy defines whether the approval is needed to install, or upgrade IBM Cloud Pak foundational services. By default, the approval strategy is set to Automatic, however, you can change this setting during installation. You can also set the approval strategy after the installation by adding or changing the installPlanApproval parameter in the custom resource. If the approval strategy is set to Automatic, the operator is automatically installed or upgraded when a new version is available. If you set the installPlanApproval parameter to Manual, the operator is not automatically installed or upgraded. Instead, you get an an install plan that needs to be manually approved before an upgrade.

Notes:

• When you set the installPlanApproval for the IBM Cloud Pak foundational services operator, it applies to all foundational services installed with this operator.
• If you install the IBM Cloud Pak foundational services operator in a namespace where another operator is installed that already has the installPlanApproval: Manual set in its subscription, then the IBM Cloud Pak foundational services operator inherits this setting. The approval plan is set to Manual and IBM Cloud Pak foundational services operator cannot be automatically installed or upgraded.

Changing approval strategy from Automatic to Manual

To change the approval strategy from Automatic to Manual, change the installPlanApproval parameter value to Manual in the spec section of the CommonService CR.

Note: If the installPlanApproval parameter is not in the CR, add the following line to the CR in the spec section: installPlanApproval: Manual.

apiVersion: operator.ibm.com/v3
kind: CommonService
metadata:
  name: common-service
  namespace: <your-foundational-services-namespace>
spec:
  installPlanApproval: Manual

Changing approval strategy from Manual to Automatic

Note: Before you begin, make sure that the operators that are not a part of IBM Cloud Pak foundational services in the namespace have the installPlanApproval parameter set to Automatic in the subscription. Otherwise, even if you change the approval strategy from Manual to Automatic for the IBM Cloud Pak foundational services operator, this setting might be overwritten.

To change the approval strategy from Manual to Automatic, complete the following steps:

1. Change the installPlanApproval parameter value to Automatic in the spec section of the CommonService CR.

Note: If the installPlanApproval parameter is not in the CR, add the following line to the CR in the spec section: installPlanApproval: Automatic.

apiVersion: operator.ibm.com/v3
kind: CommonService
metadata:
  name: common-service
  namespace: <your-foundational-services-namespace>
spec:
  installPlanApproval: Automatic

1. Change the installPlanApproval parameter value to Automatic in the IBM Cloud Pak foundational services subscription. If you have more than one IBM Cloud Pak foundational services subscription, change the value of the installPlanApproval parameter in all subscriptions.

Bring your own CA Certificate

You can replace the foundational services self-signed certificate authority (CA) certificate with your own CA certificate in either of the following ways:

• Create an issuer and generate a certificate, or create just the secret. For more information, see Bringing your own CA Certificate.
• Update the CommonService CR.

Note: Anytime you need to bring back your original certificate, see Bringing back your original CA Certificate.

If you are updating the CommonService CR to bring your own certificate, first update BYOCACertificate: true in the spec section of the CommonService CR.

Note: If BYOCACertificate specification is not in the CR, you can add it in the spec section as shown in the following example:

apiVersion: operator.ibm.com/v3
kind: CommonService
metadata:
  name: common-service
  namespace: <your-foundational-services-namespace>
spec:
  BYOCACertificate: true

After you update the CommonService CR, complete the following steps to replace the foundational services self-signed CA certificate with your own CA certificate:

1. Prepare and have your Transport Layer Security (TLS) certificate, TLS private key, and CA certificate ready.

2. Create a backup of the foundational services self-signed CA certificate. By default, the certificate is created in the <foundational-services> namespace.

    oc get certificate cs-ca-certificate -n <your-foundational-services-namespace> -o yaml > cs-ca-certificate.yaml
   

3. Delete the foundational services self-signed CA certificate resource so that the cert-manager service does not re-create the updated secret.

    oc delete certificate cs-ca-certificate -n <your-foundational-services-namespace>
   

4. Delete the foundational services self-signed CA certificate secret.

    oc delete secret cs-ca-certificate-secret -n <your-foundational-services-namespace>
   

5. Re-create the cs-ca-certificate-secret secret with your CA certificate (ca.crt), TLS certificate (tls.crt), and private key (tls.key).

    oc -n <your-foundational-services-namespace> create secret generic cs-ca-certificate-secret --from-file=ca.crt=<your path>/ca.crt  --from-file=tls.crt=<your path>/tls.crt  --from-file=tls.key=<your path>/tls.key
   

6. Refresh the leaf certificates that are created by individual foundational services. For more information and steps to refresh the leaf certificates, see Refreshing foundational services internal certificates.

License

Accept the licenses to use the services. To do so, add spec.license.accept: true in the spec section of the CRs. See the following samples:

• Foundational services license in the common-service CR.

apiVersion: operator.ibm.com/v3
kind: CommonService
metadata:
  name: common-service
  namespace: <your-foundational-services-namespace>
spec:
  license:
    accept: true
  size: as-is

• License service license in the instance CR.

apiVersion: operator.ibm.com/v1alpha1
kind: IBMLicensing
metadata:
  name: instance
spec:
  license:
    accept: true

• Certificate manager service license in the default CR.

apiVersion: operator.ibm.com/v1
kind: CertManagerConfig
metadata:
  name: default
spec:
  license:
    accept: true

• IBM NamespaceScope Operator license in the NamespaceScope CR, if your topology needs the service.

apiVersion: operator.ibm.com/v1
kind: NamespaceScope
metadata:
  name: common-service
  namespace: <<foundational-services>-namespace>
spec:
  license:
    accept: true

Hardware profile

Set the hardware requirements profile based on the workloads in your cluster. For more information about the profiles, see Hardware requirements and recommendations for foundational services.

You can use the templates to update the hardware requirements of the services that you are installing. You can also use the templates to set the configuration parameters of the services.

The default profile is starterset (starter). You can change the profile to small, medium, or large (production), if required. If you are upgrading your cluster from a previous release, the default profile setting is as-is, which means that the hardware requirements setting from the previous release is retained.

apiVersion: operator.ibm.com/v3
kind: CommonService
metadata:
  name: common-service
  namespace: <your-foundational-services-namespace>
spec:
  size: as-is

Storage class

Instead of specifying the storage class for each service in the spec.<service-name> section, you can specify a storage class for all services in the spec section. Any service that needs to use a storage class will then use this specified storage class.

apiVersion: operator.ibm.com/v3
kind: CommonService
metadata:
  name: common-service
  namespace: <your-foundational-services-namespace>
spec:
  size: as-is
  storageClass: <storage-class-name>

When you specify a storage class in the spec section, the storage class of a service is updated to reflect this value only if the service is not yet deployed. For example, MongoDB and the Monitoring service both use a storage class. If IBM Cloud Pak A specifies rook-cephfs as the storage class in the spec section and requests only for MongoDB, then MongoDB is deployed with rook-cephfs as the storage class. Though IBM Cloud Pak A did not request for the Monitoring service, internally the storage class for the Monitoring service is set as rook-cephfs. In the same cluster, if IBM Cloud Pak B then specifies rook-ceph-block as the storage class in the spec section and requests for the Monitoring service, then the service is deployed with rook-ceph-block as the storage class. The storage class for MongoDB is not changed and it continues to use rook-cephfs.

Services configuration

Add any service-related configuration in the spec.services section. First, add services: under spec:. You need to add services: section only once. You can add all services-related configuration under the same section.

apiVersion: operator.ibm.com/v3
kind: CommonService
metadata:
  name: common-service
  namespace: <your-foundational-services-namespace>
spec:
  services:

Then, add the service configuration. For example, if you are adding a storage class for MongoDB, the configuration would be as shown in the following example:

apiVersion: operator.ibm.com/v3
kind: CommonService
metadata:
  name: common-service
  namespace: <your-foundational-services-namespace>
spec:
  services:
  - name: ibm-im-mongodb-operator
    spec:
      mongoDB:
        storageClass: cephfs

General settings

Federal Information Processing Standard (FIPS)

For information on configuring foundational services to enable FIPS, see Enabling FIPS.

MongoDB settings

Storage class (ibm-im-mongodb-operator)

Specify a storage class name for the persistent volume. If you do not add the storage class configuration, the default storage class that is available in the cluster is used for MongoDB.

- name: ibm-im-mongodb-operator
  spec:
    mongoDB:
      storageClass: <storage_class_name>

Note: If you change the resource settings post upgrade, the default settings get restored.

If you are installing your IBM Cloud Pak on IBM Cloud®, use the ibmc-file-gold-gid or ibmc-block-gold storage class.

Changing the default values of the MongoDB username and password (ibm-im-mongodb-operator)

The ibm-im-mongodb-operator generates default username and password, which are random strings. You can change these parameter values before you install the IBM Cloud Pak foundational services.

1. Get the base64-encoded values of the new username and password.

echo <new-username or new-password> | base64

1. Define a YAML file of kind Secret. Use the <foundational-services> namespace, and the base64-encoded username and password values in this YAML file. Following is a sample file:

    apiVersion: v1
    kind: Secret
    metadata:
      name: icp-mongodb-admin
      namespace: <your-foundational-services-namespace>
    type: Opaque
    data:
      password: SFV6a2NYMkdKa2tBZA==
      user: dGpOcDR5Unc=
   

2. Create the secret by running the following command:

    kubectl apply -f <YAML-file-name>.yaml
   

Configuring resources for MongoDB (ibm-im-mongodb-operator)

Specify resource settings. If you do not specify a setting, the default resource settings that are available in the cluster are used for MongoDB.

replicas:
  resources:
    requests:
      cpu: <cpu-request>
      memory: <memory-request>
    limits:
      cpu: <cpu-limit>
      memory: <memory-limit>

Authentication settings

• Changing the default cpadmin username
• Delegating authentication to OpenShift
• Assigning the cloud pak administrator privileges to an OpenShift user
• Adding custom OIDC claims
• Disabling nonce
• Adding description of the login options
• Setting the preferred login options (ibm-im-operator)
• Changing the OIDC issuer URL
• Changing the provider issuer URL
• Changing the cluster name
• HA configuration
• Sample ibm-im-operator operator section in the custom resource
• Configuring resources for IM (ibm-im-operator)

Changing the default cpadmin username

The IBM Cloud Pak foundational services installation creates a default cpadmin user, who is a cluster administrator. You can customize the username by adding the defaultAdminUser parameter.

Note: If you already have a user by the name cpadmin in your cluster, you must set the defaultAdminUser parameter with a custom name that is not admin before you install foundational services. This is to avoid your admin user from being removed if you uninstall foundational services later.

- name: ibm-im-operator
  spec:
    authentication:
      config:
        defaultAdminUser: <custom-username>

Delegating authentication to OpenShift (ibm-im-operator)

Authentication with Red Hat OpenShift is enabled by default. The ibm-im-operator has the following default configuration. If you do not update these parameters, authentication with OpenShift is enabled with no prefix.

- name: ibm-im-operator
  spec:
    authentication:
      config:
        roksEnabled: true
        roksURL: <your-endpoint-URL>
        roksUserPrefix: ""

You can disable the authentication, or update the parameters as required. Following are the parameter descriptions:

• roksEnabled: Set to false: to disable authentication with Red Hat OpenShift.
• roksURL: The public service endpoint URL of your public cloud cluster. For more information about how to get the URL, see Updating OpenShift authentication.
• roksUserPrefix: Prefix to be used with the username. When you access your cluster console or CLI, you use the prefix along with the username to authenticate with OpenShift. If you are using IM with Red Hat OpenShift Kubernetes Service in the IBM Cloud, you must set the prefix to IAM#.

Assigning the cloud pak administrator privileges to an OpenShift user

If you are delegating authentication to OpenShift, you can assign the cloud pak administrator privileges to an existing OpenShift user. The user can be added to the bootstrapUserId parameter.

To add the bootstrapUserId parameter before IM service installation, see the following configuration:

- name: ibm-im-operator
  spec:
    authentication:
      config:
        bootstrapUserId: "<custom-username>"

To add the bootstrapUserId parameter after IM service installation, see Changing the default cluster administrator.

Adding custom OIDC claims

The IM service uses the default scopes and claims that WebSphere® Application Server Liberty provides. Based on your OIDC authentication requirements, you can customize the OIDC claims that are returned by the UserInfo endpoint. For more information about custom claims, see Adding custom OIDC claims.

To add the custom claims before you install the IM service, add the following configuration:

- name: ibm-im-operator
  spec:
    authentication:
      config:
        claimsSupported: "<list-of-claims>"
        claimsMap: "<list-of-claims-map>"
        scopeClaim: "profile=<list-of-claims-in-the-profile>"

See the following example:

apiVersion: operator.ibm.com/v3
kind: CommonService
metadata:
  name: common-service
  namespace: <your-foundational-services-namespace>
spec:
  size: medium
  services:
  - name: ibm-im-operator
    spec:
      authentication:
        config:
          claimsSupported: "name,family_name,display_name,given_name,preferred_username"
          claimsMap: "name=\"givenName\" family_name=\"givenName\" given_name=\"givenName\" preferred_username=\"givenName\" display_name=\"displayName\""
          scopeClaim: "profile=\"name,family_name,display_name,given_name,preferred_username\""

Disabling nonce

To improve security, nonce is enabled by default. Nonce associates a client session with an ID token and is used in authentication to ensure that attackers do not use old sessions.

To disable nonce, add the following configuration:

- name: ibm-im-operator
  spec:
    authentication:
      config:
        nonceEnabled: false

Adding description of the login options (ibm-idp-config-ui-operator)

You can configure multiple authentication types in your cluster. For more information, see Authentication types.

The authentication types that you configure in your cluster are displayed on the console login page. You can provide a short description of the authentication types in the ibm-idp-config-ui-operator by configuring these parameters. The description is then displayed on the console login page.

- name: ibm-idp-config-ui-operator
  spec:
    globalUIConfig:
      enterpriseLDAP: <Provide a short description about the enterprise LDAP authentication type.>
      defaultAuth: <Provide a short description about the default authentication type.>
      osAuth: <Provide a short description about the OpenShift authentication type.>
      enterpriseSAML: <Provide a short description about the enterprise SAML authentication type.>

Setting the preferred login options (ibm-im-operator)

If you configured multiple authentication types in your cluster, but you want the console login page to display any one or a selected set of the configured login options, you can set the preferredLogin: parameter. For example, preferredLogin:SAML,LDAP.

Use the following parameter values:

• For default authentication, use DEFAULT
• For enterprise LDAP, use LDAP
• For enterprise SAML, use SAML
• For OpenShift authentication, use ROKS

- name: ibm-im-operator
  spec:
    authentication:
      config:
        preferredLogin: <option1>,<option2>,<optionN>

Changing the OIDC issuer URL (ibm-im-operator)

Default configuration of OpenID Connect (OIDC) in your product uses <cluster_address>:443 in the authentication endpoints, which are used to authenticate users to Kubernetes. However, in the oidcIssuerURL, local host IP address is used, the default value of which is https://127.0.0.1:443/idauth/oidc/endpoint/OP. If required, you can change the oidcIssuerURL endpoint to use a hostname for Kubernetes authentication. If you want to use the .well-known/openid-configuration endpoint, you must update the oidcIssuerURL with the hostname that you want to use.

- name: ibm-im-operator
  spec:
    authentication:
      config:
        oidcIssuerURL: <https://<hostname>:443/oidc/endpoint/OP>

Changing the provider issuer URL (ibm-im-operator)

If you want to use the .well-known/openid-configuration endpoint, you must update the providerIssuerURL with the hostname that you want to use. You can use the endpoint to get the OIDC configuration information of the provider. The default setting is providerIssuerURL: ''.

- name: ibm-im-operator
  spec:
    authentication:
      config:
        providerIssuerURL: <https://<hostname>:443/idprovider/v1/auth/.well-known/openid-configuration

Changing the cluster name (ibm-im-operator)

The default cluster name is mycluster. You can change the cluster name by using the clusterName parameter. The cluster name is used in Cloud Resource Names (CRNs).

- name: ibm-im-operator
  spec:
    authentication:
      config:
        clusterName: <custom-name>

HA configuration

If you are configuring high availability (HA) in your cluster, add the following configuration for the IM operator:

- name: ibm-im-operator
   spec:
     authentication:
       replicas: 3
     pap:
       replicas: 3
     policycontroller: {}
     policydecision:
       replicas: 3
     secretwatcher: {}
     securityonboarding: {}

Sample ibm-im-operator operator section in the custom resource

Following is a sample configuration of the ibm-im-operator operator in the custom resource. The sample includes the authentication with Red Hat OpenShift and OIDC URL parameters.

- name: ibm-im-operator
    spec:
      authentication:
        config:
          bootStrapUserId: clusteradmin
          roksEnabled: true
          roksURL: 'https://c100-e.eu-de.containers.cloud.ibm.com:32301'
          roksUserPrefix: 'IAM#'
          oidcIssuerURL: 'https://c100-e.eu-de.containers.cloud.ibm.com:443/oidc/endpoint/OP'
          preferredLogin: ROKS
      oidcclientwatcher: {}
      pap: {}
      policycontroller: {}
      policydecision: {}
      secretwatcher: {}
      securityonboarding: {}

Configuring resources for IM (ibm-im-operator)

Specify resource settings. If you do not specify a setting, the default resource settings that are available in the cluster are used for IM.

  - name: ibm-im-operator
    spec:
      authentication:
        replicas: 1
        auditService:
          resources:
            limits:
              cpu:
              memory:
            requests:
              cpu:
              memory:
        authService:
          resources:
            limits:
              cpu:
              memory:
            requests:
              cpu:
              memory:
        clientRegistration:
          resources:
            limits:
              cpu:
              memory:
            requests:
              cpu:
              memory:
        identityManager:
          resources:
            limits:
              cpu:
              memory:
            requests:
              cpu:
              memory:
        identityProvider:
          resources:
            limits:
              cpu:
              memory:
            requests:
              cpu:
              memory:
      oidcclientwatcher:
        replicas: 1
        resources:
          limits:
            cpu:
            memory:
          requests:
            cpu:
            memory:
      pap:
        auditService:
          resources:
            limits:
              cpu:
              memory:
            requests:
              cpu:
              memory:
        papService:
          resources:
            limits:
              cpu:
              memory:
            requests:
              cpu:
              memory:
        replicas: 1
      policycontroller:
        replicas: 1
        resources:
          limits:
            cpu:
            memory:
          requests:
            cpu:
            memory:
      policydecision:
        auditService:
          resources:
            limits:
              cpu:
              memory:
            requests:
              cpu:
              memory:
        resources:
          limits:
            cpu:
            memory:
          requests:
            cpu:
            memory:
        replicas: 1
      secretwatcher:
        resources:
          limits:
            cpu:
            memory:
          requests:
            cpu:
            memory:
        replicas: 1
      securityonboarding:
        replicas: 1
        resources:
          limits:
            cpu:
            memory:
          requests:
            cpu:
            memory:
        iamOnboarding:
          resources:
            limits:
              cpu:
              memory:
            requests:
              cpu:
              memory:

License Service settings

Enable additional information in logs for troubleshooting purposes

By default, the License Service instance pod logs contain only the basic information about the service. You can enable the additional information in logs for troubleshooting purposes by adding the logLevel parameter to the spec section.

The available logLevel options:

• DEBUG - This option enables all debug information in logs.
• VERBOSE - This option extends the logs with information about license calculation and API calls.

Following is an example configuration:

- name: ibm-licensing-operator
  spec:
    IBMLicensing:
      logLevel: DEBUG

Configure resources for License Service (ibm-licensing-operator)

Specify resource settings. If you do not specify a setting, the default resource settings that are available in the cluster are used for License Service.

  - name: ibm-licensing-operator
    spec:
      IBMLicensing:
        resources:
          requests:
            cpu:
            memory:
          limits:
            cpu:
            memory:
      IBMLicenseServiceReporter:
        databaseContainer:
          resources:
            requests:
              cpu:
              memory:
            limits:
              cpu:
              memory:
        receiverContainer:
          resources:
            requests:
              cpu:
              memory:
            limits:
              cpu:
              memory:

Note: If you do not specify a setting, the default resource settings that are available in the cluster are used for License Service. The following are the default resource settings.

- name: ibm-licensing-operator
  spec:
    IBMLicensing:
      resources:
        requests:
          cpu: 200m
          memory: 256Mi
        limits:
          cpu: 500m
          memory: 512Mi
    IBMLicenseServiceReporter:
      databaseContainer:
        resources:
          requests:
            cpu: 200m
            memory: 256Mi
          limits:
            cpu: 300m
            memory: 300Mi
      receiverContainer:
        resources:
          requests:
            cpu: 200m
            memory: 256Mi
          limits:
            cpu: 300m
            memory: 384Mi

MustGather settings

MustGather configuration settings

Example configuration with default values:

apiVersion: operator.ibm.com/v1alpha1
kind: MustGatherConfig
metadata:
  name: default
spec:
  gatherConfig: |-
    modules="overview,system,failure,ocp,cloudpak"
    namespaces="common-service,ibm-common-services"
    labels=""

MustGather job settings

Example configuration with default values:

apiVersion: operator.ibm.com/v1alpha1
kind: MustGatherJob
metadata:
  name: example-mustgatherjob
spec:
  serviceAccountName: default
  mustgatherConfigName: default

MustGather service settings

The MustGather support information is used for troubleshooting purposes, and no backup or restore is needed.

Example configuration with default values:

apiVersion: operator.ibm.com/v1alpha1
kind: MustGatherService
metadata:
  name: must-gather-service
spec:
  # Add fields here
  persistentVolumeClaim:
    name: must-gather-pvc
    storageClassName: ""
    resources:
      requests:
        storage: 5Gi
  mustGather:
    name: must-gather-service
    replicas: 1
    serviceAccountName: default
    nodeSelector:
      node-role.kubernetes.io/worker: ""
    tolerations:
    - effect: NoSchedule
      key: dedicated
      operator: Exists
    - key: CriticalAddonsOnly
      operator: Exists
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
        - ALL
      readOnlyRootFilesystem: true
      runAsNonRoot: true
    resources:
      requests:
        memory: "64Mi"
        cpu: "50m"
      limits:
        memory: "512Mi"
        cpu: "500m"

Certificate management service settings

• Configuring resources for Certificate manager (ibm-cert-manager-operator)
• certManagerCAInjector
• certManagerController
• certManagerWebhook
• Leaf certificate refresh parameters

Configuring resources for Certificate manager (ibm-cert-manager-operator)

Specify resource settings. If you do not specify a setting, the default resource settings are used.

  - name: ibm-cert-manager-operator
    spec:
      certManager:
        certManagerCAInjector:
          resources:
            limits:
              cpu: <cpu-limit (cores)>
              memory: <memory-limit (GB)>
            requests:
              cpu: <cpu-limit (cores)>
              memory: <memory-limit (GB)>
        certManagerController:
          resources:
            limits:
              cpu: <cpu-limit (cores)>
              memory: <memory-limit (GB)>
            requests:
              cpu: <cpu-limit (cores)>
              memory: <memory-limit (GB)>
        certManagerWebhook:
          resources:
            limits:
              cpu: <cpu-limit (cores)>
              memory: <memory-limit (GB)>
            requests:
              cpu: <cpu-limit (cores)>
              memory: <memory-limit (GB)>

certManagerCAInjector

certManagerController

certManagerWebhook

Leaf certificate refresh parameters

Example configuration with a CA certificate and namespace added for leaf refresh. Each certName requires a namespace. Leaf certificates based on the CA certificate will be refreshed when the CA certificate is refreshed by cert-manager.

- name: ibm-cert-manager-operator
    spec:
      refreshCertsBasedOnCA:
      - certName: sample-common-ca-cert
        namespace: sample-namespace

Common Web UI settings

Example configuration with default values:

- name: ibm-idp-config-ui-operator
    spec:
      commonWebUI:
        replicas: 1
        resources:
          requests:
            memory: 256Mi
            cpu: 300m
          limits:
            memory: 256Mi
            cpu: 300m

Specify resource settings. If you do not specify a setting, the default resource settings that are available in the cluster are used for the common UI service.

- name: ibm-idp-config-ui-operator
  spec:
    commonWebUI:
      replicas: 1
      resources:
        requests:
          memory:
          cpu:
        limits:
          memory:
          cpu: