vania-janet/multiturn-rag-retrieval-data huggingface dataset:
The shared team and the network team are now nicely separated. But how is Application1 isolated from Shared and Application2? They are Editor for the same types of services.

This is where resource groups can help out. Each service instance (i.e. resource) has a resource group attribute that is initialized upon creation and cannot be changed. In other words, each resource is in one resource group.

Resource Group diagram:

Zoom

![Resource Group diagram](https://cloud.ibm.com/docs-content/v1/content/6a28e4ae2660b609a18e90e1239ed772f80373d6/transit-gateway/includes/solution-tutorials/includes/solution-tutorials/images/solution59-vpc-tg-dns-iam/vpc-tg-dns-iam-resource-groups.png)

Resource Group diagram

Each microservice team will be allowed the access in the corresponding resource group. The network team will have access to all of these resource groups.

The network resource group contains Transit Gateway and the DNS service. The network team has access to these resources. The shared team will have Manager acess to the DNS service. The shared team needs to write the DNS entries for the shared services.

Later in the tutorial, after all resources have been created, it can be informative to open the [Resources list](https://cloud.ibm.com/resources) in the IBM Cloud console. It is possible to filter on resource group.









 Step 1: Create a local working environment 

All the operations will be performed in a bash shell and making use of terraform and ibmcloud command. You will find instructions to download and install these tools for your operating environment in the [Getting started with solution tutorials](https://cloud.ibm.com/docs/solution-tutorials?topic=solution-tutorials-tutorials) guide.



1. Git clone the following [repository](https://github.com/IBM-Cloud/vpc-tg-dns-iam):
* Resource Group: nfsgroup:
* nfs_vg (ocf::heartbeat:LVM-activate): Started cl-nfs-1
* nfs_fs1 (ocf::heartbeat:Filesystem): Started cl-nfs-1

On the node with the active resource group nfsgroup, create two subdirectories in ${NFS_fs1}. ${NFS_fs1}/stat is used as nfs_shared_infodir for NFS lock information and ${NFS_fs1}/export is used as NFS root.

mkdir ${NFS_fs1}/stat ${NFS_fs1}/export

Create the mount points for the other exported file systems.

On both nodes, run the following command.

mkdir ${NFS_fs2} ${NFS_fs3}

Create the resources for the other two NFS file systems.

On NODE1, run the following commands.

pcs resource create nfs_fs2 Filesystem device=/dev/${NFS_vg}/${NFS_lv2} directory=${NFS_fs2} fstype=xfs --group nfsgroup

pcs resource create nfs_fs3 Filesystem device=/dev/${NFS_vg}/${NFS_lv3} directory=${NFS_fs3} fstype=xfs --group nfsgroup

Check the status of the cluster and verify that all three file system resources (nfs_fs1, nfs_fs2, nfs_fs3) are active.

pcs resource status

Sample output:

 pcs resource status
* Resource Group: nfsgroup:
* nfs_vg (ocf::heartbeat:LVM-activate): Started cl-nfs-1
* nfs_fs1 (ocf::heartbeat:Filesystem): Started cl-nfs-1
Common networking configuration issues 

IBM Cloud® Security and Compliance Center Workload Protection provides a configuration page for administrators to fine-tune the way that the agent processes network data. The following are common configuration messages and how you can resolve the issues.



  Namespaces without labels 

Namespaces must be labeled for Kubernetes Network Policies (KNPs) to define ingress and egress rules.

If a namespace is not labeled, an error is displayed in the [network security policy tool.](https://cloud.ibm.com/docs/workload-protection?topic=workload-protection-netsec_policy)

For example, if the Kube-system namespace is missing labels, you get the following error message:

All communications are displayed as allowed because a policy can't be generated: you need to assign labels to this namespace.: kube-system

To resolve this issue, assign a label to the namespace. It will take a few minutes for the change to be detected by IBM Cloud Security and Compliance Center Workload Protection.





  Cluster subnet is incomplete 

To categorize unresolved IP addresses as being inside of outside a cluster, the agent needs to know the CIDR block ranges belonging to the cluster. By default the agent looks at the kube-apiserver and kube-controller-manager processes.

If the cluster subnets cannot be discovered automatically, a message that the cluster subnet is incomplete is displayed in the [network security policy tool.](https://cloud.ibm.com/docs/workload-protection?topic=workload-protection-netsec_policy)

To resolve this issue, [configure CIDR block entries for your environment.](https://cloud.ibm.com/docs/workload-protection?topic=workload-protection-network_tsnw_cidr)

If configuring CIDR block entries for your environment doesn't resolve the issue, you might need to configure the agent to look for CIDR block ranges in other processes. Add the following to your agent configmap file:

network_topology:
pod_prefix_for_cidr_retrieval:
[<PROCESS_NAME>, <PROCESS_NAME>]

Where PROCESS_NAME is the name of the process to be searched.
Connect to an IBM Cloud using use any region.

ibmcloud target --cf-api mccp.us-south.cf.cloud.ibm.com
3. List the Orgs and Spaces you have.

ibmcloud cf orgs
ibmcloud cf spaces
4. Reuse a given space, or create a new one, for this sample application.

ibmcloud target -o <ORG TARGET>
ibmcloud account space-create enterprise
5. Set the target the proper Org and Space.

ibmcloud target -o <ORG> -s <SPACE>
6. Log into IBM Cloud Container registry and create a namespace

ibmcloud cr login
ibmcloud cr namespace-add myproject







 Extract the sample application 

Create a folder structure for move2kube to deploy this application to IBM® Cloud Foundry and migrate this application to your cluster. This structure will be explained in depth later.

Run the following commands to create this folder structure. Replace <name_of_target> with your target of choice (for example, CE for Code Engine, ROKS for Red Hat OpenShift on IBM Cloud, or IKS for IBM Kubernetes Service).

mkdir move2kube-tutorial
cd move2kube-tutorial
git clone https://github.com/konveyor/move2kube-demos.git
mkdir move2kube-demos-<name_of_target>
cd move2kube-demos-<name_of_target>
git clone https://github.com/konveyor/move2kube-demos.git
cd ..

Examine the enterprise-app source contents by running the following command:

ls move2kube-demos/samples/enterprise-app/src





 Run the Cloud Foundry installation script 

Once extracted, you can use the script in the directory to deploy the application to IBM® Cloud Foundry.



1. Set extra time to stage and start the larger components.

export CF_STAGING_TIMEOUT=30
2.
ntp: { enable: true, ntp_server_ip: "NTP_SERVER_IP" }
}

After the file is updated, run the following ansible-playbook command.

ansible-playbook --connection=local -i "localhost," powervs-services.yml -e @vars/sample_client_services_variable_file.yml

This ansible execution helps make sure that the NTP service is configured.





 Manually configuring the DNS client 

To configure DNS server, you need to create the /etc/resolv.conf file, and enter the DNS server detail as nameserver <DNS_SERVER_NAME_or_IP>





 Configuring the DNS client by using ansible automation 



1. To enable DNS service through ansible automation, download the ibm.power_linux_sap ansible-galaxy collection.

ansible-galaxy collection install ibm.power_linux_sap
2. After the ansible collection is installed, configure DNS by updating the variable file playbook/vars/sample_client_services_variable_file.yml.

client_config: {
dns: { enable: true, dns_server_ip: "DNS_SERVER_IP" }
}
3. After the file is updated, run the following ansible-playbook command.

ansible-playbook --connection=local -i "localhost," powervs-services.yml -e @vars/sample_client_services_variable_file.yml



This ansible execution helps make sure that the DNS service is configured.





 Manually configuring an NFS client 

Use to following steps to manually create an NFS client.



1. Export shared NFS directories. To make these exported NFS directories available, mount them by using NFS protocol. Then, install the nfs-client package and enable NFS client by using the systemctl command.



* On SLES:



zypper install -y nfs-utils



* On RHEL:
Review [Designing an addressing plan for a VPC](https://cloud.ibm.com/docs/vpc?topic=vpc-vpc-addressing-plan-design) to get guidance how to plan for addressing within your VPC. VPC uses [Classless Inter-Domain Routing (CIDR) notation](https://cloud.ibm.com/docs/vpc?topic=vpc-choosing-ip-ranges-for-your-vpc) for specifying addresses.
3. Create the address prefix for each zone in both VPCs based on the plan that you developed in the previous step. See [ibmcloud is vpc-address-prefix-create](https://cloud.ibm.com/docs/vpc?topic=vpc-infrastructure-cli-plugin-vpc-referencevpc-address-prefix-create) for details.
4. Create the subnets for the three zones by using the CIDRs. For more information, see [Create a subnet](https://cloud.ibm.com/docs/vpc?topic=vpc-creating-a-vpc-using-clicreate-a-subnet-cli).

You need to specify zones. For us-south, the three zones are us-south-1, us-south-2, us-south-3. For us-east, the three zones are us-east-1, us-east-2, us-east-3. See [multizone regions](https://cloud.ibm.com/docs/overview?topic=overview-locationsmzr-table) for more information, including the zone identifiers for other multizone regions.
5. Create security groups to define inbound and outbound traffic that's allowed for virtual server instances. For more information, see [Using security groups](https://cloud.ibm.com/docs/vpc?topic=vpc-using-security-groups) and [Overview of network security options](https://cloud.ibm.com/docs/openshift?topic=openshift-vpc-network-policy).
6.
For example, when you [set up Helm in your cluster](https://cloud.ibm.com/docs/containers?topic=containers-helm)







 Creating custom RBAC permissions for users, groups, or service accounts 

The view, edit, admin, and cluster-admin cluster roles are automatically created when you assign the corresponding IBM Cloud IAM service access role. Do you need your cluster access policies to be more granular than these predefined permissions allow? No problem! You can create custom RBAC roles and cluster roles.

You can assign custom RBAC roles and cluster roles to individual users, groups of users, or service accounts. When a binding is created for a group, it affects any user that is added or removed from that group. When you add users to a group, they get the access rights of the group in addition to any individual access rights that you grant them. If they are removed, their access is revoked. Note that you can't add service accounts to access groups.

If you want to assign access to a container process that runs in pods, such as a continuous delivery toolchain, you can use [Kubernetes ServiceAccounts](https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/). To follow a tutorial that demonstrates how to set up service accounts for Travis and Jenkins and to assign custom RBAC roles to the service accounts, see the blog post [Kubernetes ServiceAccounts for use in automated systems](https://medium.com/@jakekitchener/kubernetes-serviceaccounts-for-use-in-automated-systems-515297974982).

To prevent breaking changes, don't change the predefined view, edit, admin, and cluster-admin cluster roles. Custom RBAC roles are in addition to and don't change or override any RBAC roles that you might have assigned with IBM Cloud IAM service access roles.



* Namespace access: To allow a user, access group, or service account to access a resource within a specific namespace, choose one of the following combinations:
"value": "crn:v1:bluemix:public:is:us-east:a/CRN"
},
{
"type": "vpc",
"value": "crn:v1:bluemix:public:is:us-south:a/CRN"
},
{
"type": "serviceRef",
"ref": {
"service_name": "cloud-object-storage",
"account_id": "ACCOUNT-ID"
}
},
{
"type": "serviceRef",
"ref": {
"service_name": "codeengine",
"account_id": "ACCOUNT-ID"
}
},
{
"type": "serviceRef",
"ref": {
"service_name": "containers-kubernetes",
"account_id": "ACCOUNT-ID"
}
},
{
"type": "serviceRef",
"ref": {
"service_type": "platform_service",
"account_id": "ACCOUNT-ID"
}
},
{
"type": "serviceRef",
"ref": {
"service_name": "iam-groups",
"account_id": "ACCOUNT-ID"
}
}
],
"excluded": []
}





 Creating network zones from the CLI 



1. To create network zones from the CLI, [install the CBR CLI plug-in](https://cloud.ibm.com/docs/cli?topic=cli-cbr-plugininstall-cbr-plugin).
2. You can use the cbr-zone-create command to add resources to network zones.
"etcd_key_file": "__ETCD_KEY_FILE__",
"etcd_cert_file": "__ETCD_CERT_FILE__",
"etcd_ca_cert_file": "__ETCD_CA_CERT_FILE__",
"mtu": __CNI_MTU__,
"ipam": {
"type": "calico-ipam"
},
"container_settings": {
"allow_ip_forwarding": true
},
"policy": {
"type": "k8s"
},
"kubernetes": {
"kubeconfig": "__KUBECONFIG_FILEPATH__"
}
},
{
"type": "portmap",
"snat": true,
"capabilities": {"portMappings": true}
}
]
}
etcd_ca: /calico-secrets/etcd-ca
etcd_cert: /calico-secrets/etcd-cert
etcd_endpoints: https://172.20.0.1:2041
etcd_key: /calico-secrets/etcd-key
typha_service_name: none
veth_mtu: "1480"
...
Show more
3. Apply the MTU changes to your cluster master by refreshing the master API server. It might take several minutes for the master to refresh.

ibmcloud ks cluster master refresh --cluster <cluster_name_or_ID>
4. Verify that the master refresh is completed. When the refresh is complete, the Master Status changes to Ready.

ibmcloud ks cluster get --cluster <cluster_name_or_ID>
5.
* [ibmcloud oc cluster image-security enable](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics-image-security-enable)



* [ibmcloud oc cluster ls](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_clusters)
* cluster master: View and modify the master for a cluster.



* cluster master audit-webhook: View and modify the audit webhook configuration for a cluster's Kubernetes API server.



* [ibmcloud oc cluster master audit-webhook get](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_apiserver_config_get)
* [ibmcloud oc cluster master audit-webhook set](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_apiserver_config_set)
* [ibmcloud oc cluster master audit-webhook unset](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_apiserver_config_unset)



* cluster master pod-security: View and modify your Pod Security configurations.



* [ibmcloud oc cluster master pod-security get](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-get)
* [ibmcloud oc cluster master pod-security set](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clicluster-master-pod-security-set)
* [ibmcloud oc cluster master satellite-service-endpoint allowlist remove](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clicluster-master-sat-allowlist-remove)



* [ibmcloud oc cluster master private-service-endpoint enable](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_master_pse_enable)



* cluster master public-service-endpoint: Manage the public service endpoint of a cluster.



* [ibmcloud oc cluster master public-service-endpoint disable](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_cluster_master_pub_se_disable)
* [ibmcloud oc cluster master public-service-endpoint enable](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_master_pub_se_enable)



* [ibmcloud oc cluster master refresh](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_apiserver_refresh)
* [ibmcloud oc cluster master update](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_update)



* cluster pull-secret: Manage image pull secrets for the cluster to access images in IBM Cloud Container Registry.



* [ibmcloud oc cluster pull-secret apply](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_pull_secret_apply)



* [ibmcloud oc cluster rm](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_rm)
* [ibmcloud oc cluster master private-service-endpoint allowlist](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_master_pse_allowlist)
* [ibmcloud oc cluster master private-service-endpoint disable](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_master_pse_disable)
* [ibmcloud oc cluster master private-service-endpoint enable](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_master_pse_enable)
* [ibmcloud oc cluster master public-service-endpoint enable](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_master_pub_se_enable)
* [ibmcloud oc cluster master refresh](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_apiserver_refresh)
* [ibmcloud oc cluster master update](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_update)
* [ibmcloud oc cluster pull-secret apply](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_pull_secret_apply)
* [ibmcloud oc cluster rm](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_cluster_rm)
* [Horizontal pod autoscaling (HPA)](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-deploy-appshpca)



[(Deprecated) Installing the cluster autoscaler Helm chart in your cluster](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helmcluster-scaling-helm)



* [Customizing the cluster autoscaler Helm chart values](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helmca_chart_values)
* [Upgrading a cluster autoscaler Helm chart release](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helmca_helm_up)



* [Prerequisites](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helmca_helm_up_prereqs)
* [Upgrading the cluster autoscaler release version](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helmca_helm_up_general)



* [Removing the cluster autoscaler](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helmca_rm)
* [Cluster autoscaler Helm chart parameter reference](https://cloud.ibm.com/docs/openshift?topic=openshift-cluster-scaling-helmca_helm_ref)



[Updating clusters, worker nodes, and cluster components](https://cloud.ibm.com/docs/openshift?topic=openshift-updateupdate)



* [Updating the master](https://cloud.ibm.com/docs/openshift?topic=openshift-updatemaster)



* [About updating the master](https://cloud.ibm.com/docs/openshift?topic=openshift-updatemaster-about)
HA proxy aae810 68e6b3 Updated image with fixes for [CVE-2021-33910](https://nvd.nist.gov/vuln/detail/CVE-2021-33910). 
 Registry endpoints Added zonal public registry endpoints for clusters with both private and public service endpoints enabled. 
 Read only disk self healing For VPC Gen2 workers. Added automation to recover from disks going read only. 
 Kubernetes v1.19.12 v1.19.13 See the [Kubernetes release notes](https://github.com/kubernetes/kubernetes/releases/tag/v1.20.9). 







 Change log for master fix pack 1.19.13_1554, released 27 July 2021 

The following table shows the changes that are in the master fix pack patch update 1.19.13_1554. Master patch updates are applied automatically.



Changes since version 1.19.12_1551

 Component Previous Current Description 

 Cluster health image v1.2.13 v1.2.14 Updated universal base image (UBI) to the latest version to resolve CVEs. 
 etcd v3.4.14 v3.4.16 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.4.16).
OpenVPN server N/A N/A OpenVPN server is now restarted during the [cluster master refresh](https://cloud.ibm.com/docs/openshift?topic=openshift-kubernetes-service-clics_apiserver_refresh) operation. 







 Change log for 3.11.161_1538_openshift, released 20 January 2020 

The following table shows the changes that are in the patch 3.11.161_1538_openshift.



Changes since version 3.11.154_1537

 Component Previous Current Description 

 Cluster master HA Proxy 1.8.21-alpine 1.8.23-alpine See the [HA proxy release notes](https://www.haproxy.org/download/1.8/src/CHANGELOG). Update resolves [CVE-2019-1551](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1551). 
 etcd v3.3.17 v3.3.18 See the [etcd release notes](https://github.com/etcd-io/etcd/releases/v3.3.18). Update resolves [CVE-2019-1551](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-1551). 
 IBM Cloud Controller Manager v1.15.6-200 v1.15.7-229 Updated to support the Kubernetes 1.15.7 release. 
 IBM Cloud File Storage for Classic plug-in and monitor 354 357 Made the ibmc-block-gold storage class the default storage class for new clusters only. The default storage class for existing clusters is unchanged. Added the following storage classes: ibmc-file-bronze-gid, ibmc-file-silver-gid, and ibmc-file-gold-gid.
Any changes that you make to a certificate in the default Secrets Manager instance in your cluster are automatically reflected in the secret in your cluster. If you make changes to a certificate that is not hosted in your cluster Secrets Manager instance, you must use this command to update the secret in your cluster the pick up the certificate changes.

ibmcloud oc ingress secret update --cluster CLUSTER --name SECRET_NAME --namespace NAMESPACE [--cert-crn CRN] [-q]

Minimum required permissions
: Administrator platform access role for the cluster in IBM Cloud Kubernetes Service

Command options:

-c, --cluster CLUSTER
: Required: The name or ID of the cluster.

--name SECRET_NAME
: Required: The name of the secret. To see available secrets, run ibmcloud oc ingress secret ls.

--namespace NAMESPACE
: Required: The project that the secret is deployed to. To see the secret namespace, run ibmcloud oc ingress secret get --cluster cluster_name_or_ID <--name secret_name> --namespace <project>.

--cert-crn CERTIFICATE_CRN
: Optional: The certificate CRN. To see the secret CRN, run ibmcloud oc ingress secret get --cluster <cluster_name_or_ID> --name secret_name> --namespace <project>. This option requires a default [Secrets Manager](https://cloud.ibm.com/docs/openshift?topic=openshift-secrets-mgrsecrets-mgr_about) instance in your cluster.

-q
: Optional: Do not show the message of the day or update reminders.



 Example ingress secret update command 

Virtual Private Cloud

Classic infrastructure

ibmcloud oc ingress secret update --cluster my_cluster --name my_alb_secret --namespace demo_ns







 ibmcloud oc ingress status-report disable 

Virtual Private Cloud

Classic infrastructure

Disable status reporting for Ingress components in a cluster.
The master update resolves CVE-2019-11254 and CVE-2020-8552 (see the [IBM security bulletin](https://www.ibm.com/support/pages/node/6203780)), and the worker node update resolves CVE-2020-8551 (see the [IBM security bulletin](https://www.ibm.com/support/pages/node/6204874)). 
 OpenVPN server Master N/A N/A OpenVPN server is now restarted during [cluster master refresh](https://cloud.ibm.com/docs/containers?topic=containers-kubernetes-service-clics_apiserver_refresh). 
 Ubuntu 18.04 packages Worker N/A N/A Updated worker node images with package updates for [CVE-2019-19956](https://nvd.nist.gov/vuln/detail/CVE-2019-19956), [CVE-2020-7595](https://nvd.nist.gov/vuln/detail/CVE-2020-7595), [CVE-2019-18634](https://nvd.nist.gov/vuln/detail/CVE-2019-18634), [CVE-2019-3843](https://nvd.nist.gov/vuln/detail/CVE-2019-3843), [CVE-2019-3844](https://nvd.nist.gov/vuln/detail/CVE-2019-3844), [CVE-2019-20386](https://nvd.nist.gov/vuln/detail/CVE-2019-20386), and [CVE-2020-1712](https://nvd.nist.gov/vuln/detail/CVE-2020-1712).