vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more information about configuration, see [Controlling pod security admission synchronization](https://docs.openshift.com/container-platform/4.11/authentication/understanding-and-managing-pod-security-admission.htmlsecurity-context-constraints-psa-opting_understanding-and-managing-pod-security-admission) in the Red Hat OpenShift documentation. Note that the steps vary for each cluster version, so make sure you are viewing the steps for the correct version.

For more information about configuring apiserver logs for Red Hat OpenShift on IBM Cloud, see [Kubernetes API server audit logs](https://cloud.ibm.com/docs/openshift?topic=openshift-health-auditaudit-api-server).

Pod security admission provides the ability to enforce, warn, and generate audit events for pods that violate the security profiles. In OpenShift 4.11, the default configuration enforces the privileged profile, while also generating warnings and audit events based on the restricted profile. This behavior can be controlled at the namespace level through the use of predefined pod security labels on namespaces. When the Pod security profiles are enforced, you might see warnings such as the following example.
kind: ConfigMap
metadata:
creationTimestamp: "2021-06-08T04:23:35Z"
labels:
addonmanager.kubernetes.io/mode: EnsureExists
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-settings
namespace: kube-system
resourceVersion: "1253"
uid: c1d39cdb-329e-4cf4-b714-954178984a53
Show more
3. Exit the editor.
4. Find the pod name for the kubenertes-dashboard pod.

kubectl -n kube-system get pods | grep kubernetes-dashboard

kubernetes-dashboard-549b67cb67-24pft 1/1 Running 0 40d
5. Restart the dashboard by deleting the kubernetes-dashboard pod.

kubectl -n kube-system delete pod kubernetes-dashboard-xxx
globalDefault: <false>
description: "Use this class for XYZ service pods only."



Understanding the YAML file components

 Components Description 

 name Required: The name of the priority class that you want to create. 
 value Required: Enter an integer less than or equal to 1 billion (1000000000). The higher the value, the higher the priority. Values are relative to the values of other priority classes in the cluster. Reserve very high numbers for system critical pods that you don't want to be preempted (removed).<br><br>For example, the [default cluster-critical priority classes](https://cloud.ibm.com/docs/containers?topic=containers-pod_prioritydefault_priority_class) range in value from 900000000-2000001000, so enter a value less than these numbers for new priority classes so that nothing is prioritized higher than these pods. 
 globalDefault Optional: Set the field to true to make this priority class the global default that is applied to every pod that is scheduled without a priorityClassName value. Only one priority class in your cluster can be set as the global default. If there is no global default, pods with no priorityClassName specified have a priority of zero (0).<br><br>The [default priority classes](https://cloud.ibm.com/docs/containers?topic=containers-pod_prioritydefault_priority_class) don't set a globalDefault. If you created other priority classes in your cluster, you can check to make sure that they don't set a globalDefault by running kubectl describe priorityclass <name>. 
 description Optional: Tell users why to use this priority class. Enclose the string in quotations (""). 



4. Create the priority class in your cluster.

kubectl apply -f filepath/priorityclass.yaml
5. Verify that the priority class is created.

kubectl get priorityclasses



Great! You created a priority class.
You can define the admission control mode you want to use for pod security in each namespace. Kubernetes defines a set of labels that you can set to define which of the predefined Pod Security Standard profiles you want to use for a namespace. The label you select defines what action the control plane takes if a potential violation is detected.

By default, IBM Cloud Kubernetes Service adds the privileged Pod Security labels to the following namespaces. These namespaces are labeled to enforce, audit, and warn by using the privileged profile.



* kube-system
* ibm-system
* ibm-operators



Do not remove or change the labels for these namespaces.

A namespace can be labeled to set the pod security profile for any or all the Pod Security Admission modes.

For example, you can label a namespace to enforce the privileged profile in addition to using warn or audit by using the baseline profile.

This label allows administrators and application developers to dry-run applications by looking for only warnings and audit records against the baseline profile without rejecting pods. Then, you can make necessary changes to your workloads before changing the enforce mode to baseline.

The Pod Security Admission namespace labels are of the form pod-security.kubernetes.io/<MODE>: <LEVEL> and pod-security.kubernetes.io/<MODE>-version: <VERSION>.



* pod-security.kubernetes.io/enforce
* pod-security.kubernetes.io/enforce-version
* pod-security.kubernetes.io/audit
* pod-security.kubernetes.io/audit-version
* pod-security.kubernetes.io/warn
* pod-security.kubernetes.io/warn-version



To label a namespace to enforce the privileged profile and generate warnings and audit events for violations of the baseline profile, use the following labels.



* pod-security.kubernetes.io/enforce: privileged
* pod-security.kubernetes.io/enforce-version: latest
* pod-security.kubernetes.io/audit: baseline
* Pre-production destination - select this destination as low-cost push destination, for your development and test environments.
* Production destination - use the full capability of this destination. Unlimited devices and outbound messages allowed.



* Update the Safari Push Credentials with the details.



* Website Name: The website name. This is the heading that is used in Notification Center.
* Website push ID: Unique reverse-domain string for your website Push ID such as web.com.example.domain (the string must start with web).
* Website URL: The URL of the website that should be permitted to subscribe to Safari Push Notifications.
* URL format string: The URL to go to when the notification is clicked. Use %@ as a placeholder for arguments that you complete when delivering your notification. This URL must use the http or https scheme: otherwise, it is invalid.
* upload p12 certificate and provide certificate password.









 Step 5: Create an Event Notifications topic 

Select Topics in the Event Notifications console and click Create. Enter the following topic details:



* Name: enter a name for the topic.
* Description: add an optional description for the topic.
* Source: select a source from the dropdown list.
* Event type: select event type from the dropdown list.
* Event sub type select event sub type from the event sub type dropdown list.
* Severity: select severity from the severity dropdown list.
* Advanced conditions: write your own custom conditions, which must follow [jsonpath specifications](https://jsonpath.com/).







 Step 6: Create an Event Notifications subscription 

Click Subscriptions in the Event Notifications console. Enter the following subscription details:



* Click Create to display subscription wizard.
* Complete the following subscription details:



* Subscription name: name of the subscription.
* Subscription description: add an optional description.



* Under the Subscribe to a topic section, select a topic from the drop-down list and select a destination from the destination drop-down list.
* Destination type: select type under Destination and click Add.







 Step 7: Set up Event Notifications Safari web SDK
SERVICENOW_TOKEN= ServiceNow API Token
SERVICENOW_URL= ServiceNow API URL

Required Environment Variables, if you are using ServiceNow v3 provider:

IAM_ACCESS_TOKEN= Access token obtained from the IAM service corresponding to pnp-ibmcloud-api-key.
SERVICENOW_URL= ServiceNow API URL

Running the command:

cocoa change-request check-approval





 cocoa change-request prepare 

Creates the change request data and prints it to the console or a file.

Required Environment Variables:

GHE_TOKEN= Github Enterprise API Token (only required when parsing from pr)
GHE_ORG= The owner of the repository (optional, when --org is not provided)
GHE_REPO= The repository name (optional, when --repo is not provided)
EMERGENCY_LABEL= Emergency Label (optional, when --emergency-label is not provided)

The following fields can be parsed from the pull request body:

--assigned-to
--impact
--priority
--purpose
--backout-plan
--type
--customer-impact

In case they are provided by using the CLI option, the CLI option overrides the value that is found in the pull request. If all of them are provided, pr is not parsed, --org, --repo, and GHE_TOKEN is not necessary.

Options:

--org github organization where the parsed pr is (only needed if fields are parsed from pr, defaults to GHE_ORG)
--repo github repository name whre the parsed pr is (only needed if fields are parsed from pr, defaults to GHE_REPO)
--pr the pull request number to parse (mutually exclusive with sha and branch)
--sha infer the pr number from hash (mutually exclusive with pr and branch)
--branch infer PR based on the last merged pr into this branch (defaults to master)
--assigned-to A ServiceNow validated user (defaults to value found in the pull request)
If the errors, logs, or metrics do not help, review the webhook descriptions that you retrieved earlier. Each webhook configuration has a set of rules that specify the kinds of resources and actions the webhook is called for. This information can be used to identify the webhook(s) that might be involved.



* If there is an error calling the webhook, review the documentation for that service for product-specific debuggging steps.
* If the webhook is rejecting the requests, look at the policies and configuration options for the webhook. It might be possible to adjust them to allow the request. Or, the request might be violating the policies and the request or the application making the request need to be changed. For more information, see [What are the best practices for using webhooks](https://cloud.ibm.com/docs/openshift?topic=openshift-access_webhookswebhook-best-practice).







 Reviewing the service that the webhook is calling 



1. Get the details of the service and its endpoints.

kubectl get svc NAME -n NAMESPACE

kubectl get ep NAME -n NAMESPACE



* If the webhook is calling a service that doesn't exist, the webhook might be leftover from an incomplete or improper removal of an application. In this case, look for service-specific documentation and follow the steps to uninstall the service.
* If you are unable to uninstall the service, delete the webhook configuration.

kubectl delete validatingwebhookconfiguration NAME

kubectl delete mutatingwebhookconfiguration NAME



2. If the service exists, but has no endpoints, check the health of the pods. First, get the pod labels from the service.

kubectl describe svc NAME -n NAMESPACE

Example output

Selector: app=my-webhook
3. List the pods that are using the labels. For example, the label in the following command is app=mywebhook.
For more information about pod security profiles, see [Profile details](https://kubernetes.io/docs/concepts/security/pod-security-standards/) in the Kubernetes documentation.

Pod Security Admission contains three modes that define what action the control plane takes if a potential violation is detected.

enforce
: Policy violations cause the pod to be rejected.

audit
: Policy violations trigger the addition of an audit annotation to the event recorded in the audit log, but are otherwise allowed.

warn
: Policy violations trigger a user-facing warning, but are otherwise allowed.

As security standards or profiles implementations change to address new features, you can configure Pod Security Admission to use a specific version of the roles. The following versions are supported.



* A Kubernetes major.minor version (for example, v1.25)
* latest







 What if Pod Security Admission isn't the right choice for me? 

While Pod Security Admission is always enabled, it can be one of multiple admission controllers. You can configure third-party Kubernetes admission controllers to implement other security policy models that suit your use case.

If you configure Pod Security Admission to enforce, warn, and audit by using the privileged profile, then the control plane allows all pods to run. You can then configure other admission controllers to reject them.

You can install a third-party admission controller as long as it doesn't take either of the following actions.



* It doesn't install its own pod security policies (PSPs).
* It doesn't rely on PSPs to enforce parts of the policy.







 Configuring Pod Security admission namespace labels 

You can define the admission control mode you want to use for pod security in each namespace. Kubernetes defines a set of labels that you can set to define which of the predefined Pod Security Standard profiles you want to use for a namespace. The label you select defines what action the control plane takes if a potential violation is detected.

By default, Red Hat OpenShift on IBM Cloud adds the privileged Pod Security labels to the following namespaces.
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36"
},
{
"action": "log",
"clientAsn": "5089",
"clientCountryName": "GB",
"clientIP": "203.0.113.69",
"clientRequestPath": "/%3Cscript%3Ealert()%3C/script%3E",
"clientRequestQuery": "",
"datetime": "2020-04-24T10:11:24Z",
"source": "waf",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36"
},
{
"action": "log",
"clientAsn": "5089",
"clientCountryName": "GB",
"clientIP": "203.0.113.69",
"clientRequestPath": "/%3Cscript%3Ealert()%3C/script%3E",
"clientRequestQuery": "",
"datetime": "2020-04-24T10:11:24Z",
"source": "waf",
"userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36"
},
{
"action": "log",
"clientAsn": "5089",
For more information about pod security profiles, see [Profile details](https://kubernetes.io/docs/concepts/security/pod-security-standards/) in the Kubernetes documentation.

Pod Security Admission contains three modes that define what action the control plane takes if a potential violation is detected.

enforce
: Policy violations cause the pod to be rejected.

audit
: Policy violations trigger the addition of an audit annotation to the event recorded in the audit log, but are otherwise allowed.

warn
: Policy violations trigger a user-facing warning, but are otherwise allowed.

As security standards or profiles implementations change to address new features, you can configure Pod Security Admission to use a specific version of the roles. The following versions are supported.



* A Kubernetes major.minor version (for example, v1.25)
* latest







 What if Pod Security Admission isn't the right choice for me? 

While Pod Security Admission is always enabled, it can be one of multiple admission controllers. You can configure third-party Kubernetes admission controllers to implement other security policy models that suit your use case.

If you configure Pod Security Admission to enforce, warn, and audit by using the privileged profile, then the control plane allows all pods to run. You can then configure other admission controllers to reject them.

You can install a third-party admission controller as long as it doesn't take either of the following actions.



* It doesn't install its own pod security policies (PSPs).
* It doesn't rely on PSPs to enforce parts of the policy.







 Configuring Pod Security admission namespace labels 

You can define the admission control mode you want to use for pod security in each namespace. Kubernetes defines a set of labels that you can set to define which of the predefined Pod Security Standard profiles you want to use for a namespace. The label you select defines what action the control plane takes if a potential violation is detected.

By default, IBM Cloud Kubernetes Service adds the privileged Pod Security labels to the following namespaces.
: You can find the release name as the prefix of the pod name, for example, {release_name}-ibm-watson-ks-yyy-xxx. For version 1.2.0, the value is always `wks`.

BACKUP_DIR
: Required. The base directory of each database where backups are stored to or restored from. Each database is stored in a subdirectory of the backup directory. A new folder with timestamp `wks-backup-yyyymmdd_hhmmss` will be created under [backupDir], for example: [backupDir]/wks-backup-yyyymmdd_hhmmss/mongodb
: For restore: please set [backupDir] with `wks-backup-yyyymmdd_hhmmss`, for example: [backupDir]/mongodb

-n NAMESPACE
: Namespace for the pods.
: The default value is `zen`.





 Output 

The script returns the following output, indicating either the backup or restore command:

[SUCCESS] MongoDB,PostgreSQL,Minio,PVC (backup|restore)

If the process fails, the following message is displayed, indicating either the backup or restore command:

[FAIL] MongoDB,PostgreSQL,Minio,PVC (backup|restore)

If the script fails, the data is corrupted. Do not use the corrupted data to restore.







 Database-specific scripts 

If you need to back up or restore a single database, use one of the database-specific scripts. However, make sure that you deactivate the pods before you run the script, and reactivate the pods after the script completes successfully.



 MongoDB 

Use this script instead of all-backup-restore.sh to back up or restore only the MongoDB database.

mongodb-backup-restore.sh backup|restore RELEASE_NAME BACKUP_DIR -n NAMESPACE

Use either the backup or restore command.
After the device is subscribed to a particular tag, the device can receive notifications that are sent for that tag. Add the following code snippet to your web application to subscribe to a list of tags.

enPush.subscribe(tagName, function(response) {
alert(response.response)
})
* When the setup is complete, run your application and register for push notifications.







 Step 8: Send notifications to the Safari Web device 

Use the [Send Notification API](https://cloud.ibm.com/apidocs/event-notifications/event-notificationssend-notifications) to send the push notification for the Firefox device. You can use the [Node](https://github.com/IBM/event-notifications-node-admin-sdksend-notifications) or [Go](https://github.com/IBM/event-notifications-go-admin-sdksend-notifications) admin SDK instead of calling the API directly.

Zoom

![Receive notifications](https://cloud.ibm.com/docs-content/v1/content/4c9a07fe500838e5e55e71e73131ef20b44a6c66/event-notifications/images/en_receive_safari_push_notification.png)

Figure 16. Receive notifications
* [iOS Push Notifications (APNs)](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-push-apns)
* [Chrome Push Notifications](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-push-chrome)
* [Firefox Push Notifications](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-push-firefox)
* [Safari Push Notifications](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-push-safari)
* [Huawei Push Notifications](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-push-huawei)



* [Slack](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-destinations-slack)
* [ServiceNow](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-destinations-servicenow)



Both Email and SMS destinations are provided out of the box, and are available whenever you create an instance of Event Notifications. IBM Cloud push notification service must be added manually and requires configuration.





 Service destinations 

Service destinations are cloud services or application where notifications are consumed programmatically. The following service destination is supported by the Event Notifications service:



* [Webhook](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-destinations-webhook)
* [IBM Cloud Functions](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-destinations-cloud-functions)
* [Code Engine](https://cloud.ibm.com/docs/event-notifications?topic=event-notifications-en-destinations-codeengine)
paths array[Path Object] Yes A list of path objects that define the endpoints that you want to protect. If not specified, all paths are protected. 









 Deleting the Adapter 

To remove the Adapter and all associated CRDs, you must delete the Helm chart and the associated signing and encryption keys.

helm delete --purge appidentityandaccessAdapter
kubectl delete secret appidentityandaccessAdapter-keys -n istio-system





 Configuring logging 

By default, logs are styled as JSON and provided at an info visibility level to provide for ease of integration with external logging systems. To update the logging configuration, you can use the Helm chart. Supported logging levels include range [-1, 7] as shown in Zap core. For more information about the levels, see the [Zap core documentation](https://pkg.go.dev/go.uber.org/zap/zapcoreLevel).

When you're manually viewing JSON logs, you might want to tail the logs and "pretty print" them by using [jq](https://brewinstall.org/install-jq-on-mac-with-brew/).



 Adapter 

To see the Adapter logs, you can use kubectl or access the pod from the appidentityandaccessAdapter pod from the Kubernetes console.

alias Adapter_logs="kubectl -n istio-system logs -f $(kubectl -n istio-system get pods -lapp=appidentityandaccessAdapter -o jsonpath='{.items[0].metadata.name}')"
Adapter_logs | jq





 Mixer 

If the Adapter does not appear to receive requests, check the Mixer logs to ensure that it connected successfully to the Adapter.
The command can identify emergency pull requests marked with a label, in this case it has an exit code of 0.

Required Environment Variables:

GHE_TOKEN= Github Enterprise API Token (Optional if you are using --git-token-path field)
GHE_ORG= The owner of the repository
GHE_REPO= The repository name
INCIDENT_ISSUE_REPO= The incident issue repo name
EMERGENCY_LABEL= Emergency Label name
GIT_COMMIT= Commit hash of the Pull Request

Options:

--label Label to add to possible pr incident issue
--git-provider SCM provider (GitHub)
--git-token-path (Optional) GitHub Token's path
--git-api-url (Optional) GitHub API url

If you are using GitHub, you can use --git-token-path field to set your GitHub Token and --git-api-url field to set the # GitHub Enterprise API URL instead of GHE_TOKEN and GH_URL environment variables. If both of them are provided, --git-token-path and --git-api-url take precedence.

Running the command:

cocoa check pull-request-approval





 cocoa check pull-request-status 

Checks a given Pull Request's status and the repositories settings.



* Branch Protection: Rules to disable force pushing, prevent branches from being deleted, and optionally require status checks before merging.
* Commit Status Check: External services to mark commits with an error, failure, pending, or success state, which is then reflected in pull requests that involve those commits.
* Check Runs: Apps that perform continuous integration, code linting, or code scanning services and provide detailed feedback on commits.



Required Environment Variables:

REQUIRED_CHECKS= Minimum required checks to be compliant set by client
GIT_BRANCH= Branch name for branch protection check
GIT_COMMIT= Commit hash of the Pull Request
GHE_TOKEN= Github Enterprise API Token (Optional if you are using --git-token-path field)
GHE_ORG= The owner of the repository