vania-janet/multiturn-rag-retrieval-data huggingface dataset:
For more best practices from IBM Garage for Cloud, see [Managing access to resources in IBM Cloud](https://develop.cloudnativetoolkit.dev/resources/ibm-cloud/access-control/).



 Sample access policies 

Review the following sample access policies to help you determine how you might want to assign access to an access group for resources that are organized in resource groups.



* A policy that grants the access group a platform administrator role on the IBM Cloud Kubernetes Service across the entire account. The users in the access group can access all instances of this service and create instances of the service in any resource group that they have at least a viewer role assigned. Access group members with an administrator role that is assigned on any resource can also grant access to that resource.
* A policy that grants the access group a platform viewer role on a resource group, but not its member resources. The users in the access group have visibility to the resource group, which is required to create instances of any service in this resource group.
* A policy that grants the access group a platform editor role on all resources in the resource group. The users in the access group can edit or delete that resource.
* A policy that grants the access group a platform administrator role on the entire account (all IAM-enabled services). The users in the access group can perform any platform actions on any resource in the entire account and management actions, such as managing the resource groups in the account.









 What makes a good trusted profiles strategy? 

A trusted profile is a grouping of federated users or compute resources to which the same IAM access can be granted. All identities that are allowed to apply a single profile inherit the same access. To reduce the number of policies in an account, you can add compute resources and federated users to the same trusted profile if their access needs are the same.

A logical way to assign access to your resource groups and the included resources is by [creating one trusted profile](https://cloud.ibm.com/docs/account?topic=account-create-trusted-profile) per required level of access. Then, you can map each trusted profile to the previously created resource groups. For example, to control access to the CustApp project, you might create the following trusted profiles:
Peer (Hyperledger Fabric v1.4) 1.1 2.8 200 (includes 100GB for peer and 100GB for state database) 
 Peer (Hyperledger Fabric v2.x) 0.7 2.0 200 (includes 100GB for peer and 100GB for state database) 
 CA 0.1 0.2 20 
 Ordering node 0.35 0.7 100 
 Operator 0.1 0.2 0 
 Console 1.2 2.4 10 



Note that when smart contracts are installed on peers that run a Fabric v2.x image, the smart contract is launched in its own pod instead of a separate container on the peer, which accounts for the smaller amount of resources required on the peer.

If you plan to deploy a five node Raft ordering service, note that the total of your deployment will increase by a factor of five. So a total of 1.75 CPU, 3.5 GB of memory, and 500 GB of storage for the five Raft nodes. A 4x16 Kubernetes two worker node cluster is minimally recommended to allow plenty of CPU for the Raft cluster and any other nodes you deploy.









 Persistent storage considerations 

IBM Blockchain Platform requires persistent storage for each CA, peer, and ordering node. When you deploy a standard Kubernetes cluster in IBM Cloud, it uses a pre-configured storage class that is backed by [IBM Cloud File Storage](https://cloud.ibm.com/docs/FileStorage?topic=FileStorage-getting-started). You have the option to upgrade your storage class, change your backing storage, or use third-party services.

Every cluster on your Kubernetes cluster on IBM Cloud comes with predefined, default storage class that is used to provision persistent storage on IBM Cloud. When you deploy a blockchain node to that cluster by using the IBM Blockchain Platform console or the APIs, the node uses this default storage class to dynamically provision the amount of storage that you specify on IBM Cloud.

For IBM Cloud Kubernetes service, the default storage class is Gold File Storage backed by [Endurance File Storage](https://cloud.ibm.com/docs/FileStorage).
The goal is to modernize continuous delivery by providing industry specifications for pipelines, workflows, and other building blocks. With Tekton, you can build, test, and deploy across cloud providers or on-premises systems by abstracting the underlying implementation details. Tekton pipelines are built into [Continuous Delivery](https://www.ibm.com/cloud/blog/announcements/build-and-deliver-using-tekton-enabled-pipelines). For more information about the IBM Cloud® Kubernetes Service, see [IBM Cloud® Kubernetes Service](https://www.ibm.com/garage/method/practices/run/tool_ibm_container).

The template that is used in this tutorial works with the Standard plan for a set of virtual machines.

You can use a deployment strategy to update an application in a production environment, in a controlled manner. Using a deployment strategy can provide the following benefits:



* Avoid application downtime.
* Enable production testing of new functions without impacting customers.
* Limit the impact of production issues to a subset of users.
* Enable rapid rollback to the previous version if issues are found.



Many possible deployment strategies are available. In general, they depend on running multiple instances of the application and managing how the various instances are updated. You can pre-configure the following common deployment strategies in Continuous Delivery:

Basic
: Deploys the new release by stopping and updating all of the running instances simultaneously, causing downtime. For rollback, you must deploy the previous version again, which causes extra downtime. Although this strategy is simple, fast, and has low runtime resource requirements, it is the riskiest and causes downtime. The Basic deployment strategy is not recommended for critical apps that must be highly available.

Rolling update
: Similar to the Basic strategy, this deployment strategy is simple, fast, and has low runtime resource requirements. However, because each running instance is taken down and updated individually, avoiding downtime, rollback requires you to deploy the previous release again. This time consuming approach might cause issues if the current version of the app in production is broken.

Blue-Green deployment
IBM Cloud Controller Manager v1.19.7-4 v1.19.8-2 Updated to support the Kubernetes 1.19.8 release, to use Go version 1.15.8, and to use calicoctl version 3.16.7. Updated image to implement additional IBM security controls and for [DLA-2509-1](https://www.debian.org/lts/security/2020/dla-2509). Updated version 1.0 and 2.0 network load balancers (NLBs) to run as a non-root user by default, with privileged escalation as needed. 
 IBM Cloud File Storage for Classic plug-in and monitor 385 388 Improved the retry logic for provisioning persistent volume claims (PVCs). 
 IBM Cloud RBAC Operator f859228 86de2b7 Updated to use Go version 1.15.7. 
 Key Management Service provider v2.2.3 v2.2.5 Updated to use Go version 1.15.7. Updated image to implement additional IBM security controls. 
 Kubernetes v1.19.7 v1.19.8 See the [Kubernetes release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.19.8). 
 Load balancer and load balancer monitor for IBM Cloud Provider 1078 1165 Updated to run as a non-root user by default, with privileged escalation as needed. Updated to use Go version 1.15.7.
Part 4: Set up a Continuous Compliance (CC) toolchain 

This tutorial is part 4 of a 4-part tutorial series where you learn IBM Cloud® DevSecOps best practices by using a complete reference implementation that is available as a service and powered by IBM Cloud® Continuous Delivery. In part 4 of this tutorial series, you use the toolchain template for continuous compliance (CC) to ensure that your deployed artifacts and their source repositories are always compliant.



 Before you begin 

Before you begin part 4 of this tutorial series, ensure that you completed the following prerequisites:



1. Complete [Part 1: Set up prerequisites](https://cloud.ibm.com/docs/devsecops?topic=devsecops-tutorial-cd-devsecops).
2. Complete [Part 2: Set up a Continuous Integration (CI) toolchain](https://cloud.ibm.com/docs/devsecops?topic=devsecops-tutorial-ci-toolchain).
3. Complete [Part 3: Set up a Continuous Deployment (CD) toolchain](https://cloud.ibm.com/docs/devsecops?topic=devsecops-tutorial-cd-toolchain).



When you set up the CC toolchain by using the template in this tutorial, you might reuse some or all of the resources that were created during the CI and CD toolchain setup process. The toolchain consists of resources such as IBM Cloud® Secrets Manager vault, IBM Cloud Kubernetes Service cluster, IBM Cloud® Container Registry namespace, IBM Cloud API key, IBM Cloud CLI, IBM Cloud Object Storage instance and bucket, IBM Cloud Satellite cluster group and application, and inventory repositories. It helps to keep the resource information from the CI and CD toolchains handy.





 Continuous Compliance (CC) toolchain introduction 

DevSecOpsintegrates a set of security and compliance controls into the [DevOps](https://www.ibm.com/cloud/learn/devops-a-complete-guide) processes.
We recommend using the [IBM Cloud Monitoring](https://www.ibm.com/cloud/cloud-monitoring) tool in combination with your IBM Cloud Kubernetes dashboard to monitor your Kubernetes resource usage. When you determine that a worker node is running out of resources, you can add a new larger worker node to your cluster and then delete the existing working node.

While it takes less effort to deploy enough resources to your Kubernetes cluster from the start and therefore be able deploy and expand resources without having to increase the resources in your cluster, the bigger the deployment, the more it will cost. Users need to consider their options carefully and recognize the tradeoffs that they are making regardless of the option that they choose.

You can scale your cluster manually by monitoring your nodes and either adding more nodes or larger nodes. While this process can be labor intensive, it has the advantage of allowing the user to always be certain what is being charged to their cloud account.

A Kubernetes cluster on IBM Cloud includes the ability to use an autoscaler that can scale your worker nodes up or down in response to your pod spec settings and resource requests. For more information about the autoscaler and how to set it up, see [Scaling Kubernetes clusters](https://cloud.ibm.com/docs/containers?topic=containers-caca) or [Scaling OpenShift clusters](https://cloud.ibm.com/docs/openshift?topic=openshift-ca) in the IBM Cloud documentation. Note that allowing the autoscaler to adjust your resources will result in charges to your IBM Cloud account that will vary automatically with your usage.

To scale manually in the console, click the node that you want to adjust on the Nodes page and then click the Usage tab. You can see a button called Reallocate, which will launch a Resource allocation tab that is very similar to the one that you saw when you created the node. If you want to lower the amount of available resources, simply provide lower values and click Reallocate resources on that tab and the resulting Summary page.

If you want to increase the CPU and memory for a node, use the Resource allocation panel in the console to increase the values. The white box at the end of the page adds up the new values.
Two zones are better than one, but three are recommended for HA to increase the likelihood that the two additional zones can absorb the workload of any single zone failure. When redundant peers from the same organization and channel, and ordering nodes, are spread across multiple zones, a failure in any one zone should not affect the ability of the network to process transactions because the workload will shift to the blockchain nodes in the other zones.

You can use the IBM Blockchain Platform console to specify the zone where a CA, peer, or ordering node is created. When you deploy a CA, peer, or ordering service (or a single ordering node), check the Advanced deployment option that is labeled Deployment zone selection to see the list of zones that is currently configured for your Kubernetes cluster.

If you're deploying a CA, peer, or ordering service, you have the option to select the zone from the list of zones available to your cluster or to let your Kubernetes cluster decide for you by leaving the default selected. For a five node ordering service, these nodes will be distributed into multiple zones by default, depending on the relative space available in each zone. You also have the ability to distribute a five node ordering service yourself by unselecting the default option to have the zones chosen for you and distributing these nodes into the zones you have available. If you are deploying a redundant node (that is, another peer when you already have one), it is a best practice to deploy this node into a different zone. You can check which zone the other node was deployed to by opening the tile of the node and looking under the Node location. Alternatively, you can use the APIs to deploy a peer or orderer to a specific zone. For more information on how to do this with the APIs, see [Creating a node within a specific zone](https://cloud.ibm.com/docs/blockchain?topic=blockchain-ibp-v2-apisibp-v2-apis-zone).

The CA zone selection is only available when the default database type SQLite is used and your cluster is configured with multiple zones.
The log collection service is a Kubernetes ClusterIP service that is created from an image from the public IBM Cloud registry. This service exposes a simple node.js HTTP web server app that is exposed only on the private network. The web server app parses the log data from the audit webhook and creates each log as a unique JSON line. Finally, the logging agent forwards the logs from the web server app to IBM Log Analysis, where you can view the logs.

Before you begin: Ensure that you reviewed the [considerations and prerequisites](https://cloud.ibm.com/docs/containers?topic=containers-health-auditprereqs-apiserver-logs) and that you have the [Administrator IBM Cloud IAM platform access role](https://cloud.ibm.com/docs/account?topic=account-userroles) for IBM Log Analysis.



1. Target the global container registry for public IBM Cloud images.

ibmcloud cr region-set global
2. Optional: For more information about the kube-audit image, inspect icr.io/ibm/ibmcloud-kube-audit-to-logdna.

ibmcloud cr image-inspect icr.io/ibm/ibmcloud-kube-audit-to-logdna
3. Create a configuration file named ibmcloud-kube-audit.yaml. This configuration file creates a log collection service and a deployment that pulls the icr.io/ibm/ibmcloud-kube-audit-to-logdna image to create a log collection container.

Kubernetes

apiVersion: v1
kind: List
metadata:
name: ibmcloud-kube-audit
items:
- apiVersion: v1
kind: Namespace
metadata:
name: ibm-kube-audit
labels:
pod-security.kubernetes.io/enforce: restricted
pod-security.kubernetes.io/enforce-version: latest
pod-security.kubernetes.io/audit: restricted
pod-security.kubernetes.io/audit-version: latest
Each Policy applies exclusively to the Kubernetes namespace in which the object lives and can specify the services, paths, and methods that you want to protect.

apiVersion: "security.cloud.ibm.com/v1"
kind: Policy
metadata:
name: samplepolicy
namespace: sample-app
spec:
targets:
-
serviceName: <svcSampleApp>
paths:
- exact: /web/home
method: ALL
policies:
- policyType: oidc
config: <oidcProviderConfig>
rules:
- claim: scope
match: ALL
source: access_token
values:
- appid_default
- openid
- claim: amr
match: ANY
source: id_token
values:
- cloud_directory
- google

- exact: /web/user
method: GET
policies:
- policyType: oidc
config: <oidcProviderConfig>
redirectUri: https://github.com/ibm-cloud-security/app-identity-and-access-Adapter
- prefix: /
method: ALL
policies:
-
policyType: jwt
config: <jwtConfig>

Service object

Path object

Policy object



Table 2. Understanding the service object components

 Service Object Type Required Description 

 serviceName string Yes The name of Kubernetes service in the Policy namespace that you want to protect. 
 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
service.kubernetes.io/ibm-load-balancer-cloud-provider-zone: "dal12" Deploy the load balancer to a specific zone in your cluster
hpaSpec: Specify the minimum number of pod replicas
minReplicas: 2
tolerations: Schedule the custom gateway pods onto edge nodes
- key: dedicated
value: edge
env:
- name: TERMINATION_DRAIN_DURATION
value: 30s
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- podAffinityTerm:
labelSelector:
matchExpressions:
- key: app
operator: In
values:
- istio-ingressgateway
topologyKey: kubernetes.io/hostname
weight: 100
nodeAffinity: Example node affinities to control the zone or the edge
preferredDuringSchedulingIgnoredDuringExecution: Could be requiredDuringSchedulingIgnoredDuringExecution instead
nodeSelectorTerms:
- matchExpressions:
- key: ibm-cloud.kubernetes.io/zone
operator: In
values:
- "dal12" Deploy the load balancer to a specific zone in your cluster
preferredDuringSchedulingIgnoredDuringExecution:
- preference:
matchExpressions:
- key: dedicated
operator: In
values:
- edge
weight: 100

Show more





 Creating a custom egress gateway 

In version 1.8 and later of the managed Istio add-on, you can create custom egress gateways. Egress gateways serve as the exit point for all outbound traffic from apps in the service mesh to external destinations.

For example, to create a custom egress gateway, you can apply the following YAML file for an IOP in your cluster.

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
namespace: ibm-operators
IBM Cloud File Storage for Classic plug-in 338 342 The File Storage for Classic plug-in is updated as follows:<br><br><br><br> * Supports dynamic provisioning with [volume topology-aware scheduling](https://cloud.ibm.com/docs/containers?topic=containers-file_storagefile-topology).<br> * Ignores persistent volume claim (PVC) delete errors if the storage is already deleted.<br> * Adds a failure message annotation to failed PVCs.<br> * Optimizes the storage provisioner controller's leader election and resync period settings, and increases the provisioning timeout from 30 minutes to 1 hour.<<br> * Checks user permissions before starting the provisioning.<br> * Adds a CriticalAddonsOnly toleration to the ibm-file-plugin and ibm-storage-watcher deployments in the kube-system namespace.<br><br><br> 
 Key Management Service provider 111 122 Added retry logic to avoid temporary failures when Kubernetes secrets are managed by IBM Key Protect for IBM Cloud. 
 Kubernetes v1.12.4 v1.13.2 See the [Kubernetes release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.13.2). 
 Kubernetes configuration N/A N/A The Kubernetes API server audit policy configuration is updated to include logging metadata for cluster-admin requests and logging the request body of workload create, update, and patch requests. 
 Kubernetes DNS autoscaler 1.2.0 1.3.0 See the [Kubernetes DNS autoscaler release notes](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler/releases/tag/1.3.0).
In part 1 of this tutorial series, you review some background information and set up prerequisites.

Schematics Continuous Delivery

+1

DevSecOps



* 1 hour
* 2023-01-13



[Part 1: Set up prerequisites](https://cloud.ibm.com/docs/devsecops?topic=devsecops-tutorial-cd-devsecops)Part 1: Set up prerequisites

This tutorial is part 1 of a 4-part tutorial series where you learn IBM Cloud® DevSecOps best practices by using a complete reference implementation that is available as a service and powered by IBM Cloud® Continuous Delivery. In part 1 of this tutorial series, you review some background information and set up prerequisites.

Kubernetes service Continuous Delivery

+1

DevSecOps



* 1 hour
* 2022-07-14



[Deploying apps to clusters with Continuous Delivery and Satellite Config](https://cloud.ibm.com/docs/satellite?topic=satellite-sat_toolchain_tutorial)Deploying apps to clusters with Continuous Delivery and Satellite Config

Deploy Kubernetes resources, like deployments, from your GitHub or GitLab repository to multiple clusters with IBM Cloud® Continuous Delivery and Satellite Config.

Satellite Continuous Delivery



* 30 minutes
* 2022-12-14



[Continuous Deployment to Kubernetes](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-continuous-deployment-to-kubernetes)Continuous Deployment to Kubernetes

This tutorial walks you through the process setting up a continuous integration and delivery pipeline for containerized applications running on the Kubernetes Service. You will learn how to set up source control, then build, test and deploy the code to different deployment stages. Next, you will add integrations to other services like Slack notifications.

Kubernetes service Container Registry

+1

Continuous Delivery



* 1 hour
* 2023-05-08
IBM Cloud Foundry migration tooling 

IBM® Cloud Foundry is deprecated and no longer supported as of 1 June 2023. For more information, see the [deprecation details](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-deprecationdep_details).

While no specific migration tool exists to automatically migrate your IBM® Cloud Foundry application to a new IBM Cloud compute service, there are certain projects that exist that move applications between Kubernetes container deployment computes.

[Konveyor.io](http://Konveyor.io) is an open source project that helps the adoption and transformation of application from many sources to various Kubernetes offerings. Transformation support includes items like re-platforming (moving to a new platform) and re-factoring (improving the application to work more efficiently on the new platform). This is a potential method for you to continue the investigation of your IBM® Cloud Foundry applications, and assist in your migration to Kubernetes-based IBM Cloud offerings such as IBM Cloud Code Engine, IBM Cloud Kubernetes Service, or Red Hat OpenShift on IBM Cloud.

[Move2Kube](https://move2kube.konveyor.io/) is a sub-project within Konveyor.io, and is a command-line tool that accelerates the process of re-platforming to Kubernetes-based platforms. It does so by analyzing the environment and source artifacts, asking guidance from the user when required. You can customize the generation of the directory structure and artifacts in the format required for your project.

This tool can also be used to gather information about your IBM® Cloud Foundry applications, even without migrating the applications. Use the move2kube collect -a cf command to obtain information about your IBM® Cloud Foundry applications, similar to the way described manually in [IBM® Cloud Foundry application deployment analysis.](https://cloud.ibm.com/docs/cloud-foundry-public?topic=cloud-foundry-public-deprecation_deploy_analysis)