rh-mobb / documentation Goto Github PK

https://mobb.ninja/docs/idp/okta-grp-sync/

has a link to https://mobb.ninja/docs/idp/okta/ which is a doc that has been deleted. Need to discuss how to handle the link, possibly just remove the link from the text in the doc short term

In the following documentation https://mobb.ninja/docs/rosa/vpn/ in the section Configure your OpenVPN Client there is a step regarding to add DNS entry for the AWS Resolver 10.x.x.2 in the OS. There is an option when you create the AWS VPN Client endpoint where you can set up the DNS server that will be use for the Client VPN:

You can set up the option also via AWS CLI with the option aws create-client-vpn-endpoint --dns-servers <value> .

With the previous option, you don't need to add the DNS nameserver, so you can avoid the Note from the documentation.

I recently came across a conversation about Azure Key Vault that pointed to this Red Hat Knowledge Article stating that it is not supported and can (will?) cause issues when the cluster is upgraded.

Can the MOBB team reconcile that article with the instructions you have documented here? Either it will break upgrades and we should not tell people to install it, or it no longer has that problem and the Knowledge article should be removed. Thank you.

Hello,

As the maintainer of the spellcheck GitHub action I was searching of users of version 0.16.0 of the Spellcheck GHA, as part of my sunset policy. I can see that you are referencing it in your code, but the code is commented out.

Do you need assistance or a PR to get it to work, if so please let me know and I will do my best to help and you to assist you.

Attempted to follow the doc below with a customer on ROSA with Openshift Version 4.13.4:

Git Link:
https://github.com/rh-mobb/documentation/blob/main/content/docs/rosa/aws-secrets-manager-csi/_index.md

Weblink:
https://mobb.ninja/docs/rosa/aws-secrets-manager-csi/

When we tried to boot up a pod we kept getting the following error:

Warning: would violate PodSecurity "restricted:v1.24": allowPrivilegeEscalation != false (container "my-application-deployment" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "my-application-deployment" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "my-application-deployment" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "my-application-deployment" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

Error from server (Forbidden): error when creating "STDIN": pods "my-application" is forbidden: my-application uses an inline volume provided by CSIDriver secrets-store.csi.k8s.io and namespace my-application has a pod security enforce level that is lower than privileged

Which sounded like something at the namespace level was blocking us from using the privileged scc. We found this documentation:

https://kubernetes.io/docs/tutorials/security/cluster-level-pss/

And the customer was able to work around the issue by removing the pod-security.kubernetes.io/enforce: privileged flag which we assume was added by default since we are using ROSA.

Going to try to work this week to see if we can use a lesser SCC policy since it looks to me like the DaemonSet does not actually require privileged access:

https://github.com/aws/secrets-store-csi-driver-provider-aws/blob/main/deployment/aws-provider-installer.yaml

securityContext:
  privileged: false
  allowPrivilegeEscalation: false

We want to ensure our content is searchable across all Red Hat properties. We also want to ensure that our site has a search function that allows for people to find the content that they need. Successful implementation of Red Hat search would include:

• Adding Red Hat's corporate search bar to the site
• Ingesting our articles into the Red Hat corporate search system
• Validating that search results are correctly displayed on page.

Depending on the timing of these items, we may want to enable hugo's static search as an interim measure.

Hi, document https://cloud.redhat.com/experts/aro/clf-to-azure/ provides step nr 5:
"Deploy the OpenShift Elasticsearch Operator and the Red Hat OpenShift Logging Operator"

But Openshift Elasticsearch Operator is deprecated and should be replaced with Loki Operator? Elsewhere in Openshift documentation:

"The OpenShift Elasticsearch Operator is deprecated and is planned to be removed in a future release. Red Hat provides bug fixes and support for this feature during the current release lifecycle, but this feature no longer receives enhancements. As an alternative to using the OpenShift Elasticsearch Operator to manage the default log storage, you can use the Loki Operator."

Actually, i would not mind skipping both Elasticsearch or Loki operator. I would like to get logs out of ARO with the log forwarder. Somehow now when reading other instructions, i end up in creating bucket when installing the Loki Operator https://docs.openshift.com/container-platform/4.13/logging/log_storage/installing-log-storage.html

Am i forced to create Azure bucket (for LokiStack) for being able to get logs out of ARO to log forwarder?

https://github.com/rh-mobb/documentation/tree/main/docs/idp/azuread#create-the-client-secret

Step 2 says Remember the Secret ID to be used later in the OCM OAuth configuration. That is incorrect. You need to use the secret, not the secret ID when configuring in OCM.

On the documentation Enabling the AWS EFS CSI Driver Operator on ROSA, it uses the SG from the worker nodes to set up the Inbound rule for the EFS Mount Target:

SG=$(aws ec2 describe-instances --filters \
  "Name=private-dns-name,Values=$NODE" \
  --query 'Reservations[*].Instances[*].{SecurityGroups:SecurityGroups}' \
  --region $AWS_REGION \
  | jq -r '.[0][0].SecurityGroups[0].GroupId')

The correct would be to use the default SG created on the VPC which has no other rules, and is ready to be used. By default, when creating the EFS Filesystem, it selects the default SG from the VPC, we only need to change it later to add the NFS rule.

Here, at "Via the AWS CLI", step 3, I changed the way and here I mention to have the EFSID in hands for later to retrieve the MOUNTTARGET and SG:

EFSID=<please replace with the EFS filesystem ID>
NODE=$(oc get nodes --selector=node-role.kubernetes.io/worker \
  -o jsonpath='{.items[0].metadata.name}')
VPC=$(aws ec2 describe-instances \
  --filters "Name=private-dns-name,Values=$NODE" \
  --query 'Reservations[*].Instances[*].{VpcId:VpcId}' \
  | jq -r '.[0][0].VpcId')
CIDR=$(aws ec2 describe-vpcs \
  --filters "Name=vpc-id,Values=$VPC" \
  --query 'Vpcs[*].CidrBlock' \
  | jq -r '.[0]')
MOUNTTARGET=$(aws efs describe-mount-targets --file-system-id $EFSID \
  | jq -r '.MountTargets[0].MountTargetId')
SG=$(aws efs describe-mount-target-security-groups --mount-target-id $MOUNTTARGET \
  | jq -r '.SecurityGroups[0]')

The official documentation does not mention about the SG when creating the EFS filesystem, just to copy the SG ID to be used later.

the document https://access.redhat.com/solutions/7064794

needs to be redirecting customers to
https://learn.microsoft.com/en-us/azure/azure-monitor/containers/kubernetes-monitoring-enable?tabs=cli#enable-container-insights

az k8s-extension create --name azuremonitor-containers --cluster-name --resource-group --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.useAADAuth=false

I wouldnt do machine configuration changes

OCP/ROSA docs have default controller replicas of 2 replicas
https://docs.openshift.com/container-platform/4.13/networking/ingress-operator.html#nw-ingress-controller-configuration-parameters_configuring-ingress
what's the motivation behind having 3 replicas in ARO?

since https://mobb.ninja/docs/aro/add-infra-nodes/ was written, Azure started offering (like this last weekend) zero cost OCP subscription for infra nodes. we should update the doc to include that information, as well as updating the helm chart it uses to ensure we follow the guidelines to get the free subs.

here's the freshly minted Azure doc... note it mentions specific instance types, node labels, and workloads.

https://learn.microsoft.com/en-us/azure/openshift/howto-infrastructure-nodes#qualified-workloads

Currently blockquotes are not properly styled. This needs to be completed to ensure block quotes are properly aligned.

Hi,
The documentation only provides details for a STS cluster - https://github.com/rh-mobb/documentation/blob/main/content/rosa/aws-load-balancer-operator/index.md

Is there documentation available for a Non STS cluster to create the required secrets?

https://github.com/openshift/aws-load-balancer-operator/issues/121

On https://cloud.redhat.com/experts/rosa/sts/ , the Prerequisites link to https://cloud.redhat.com/experts/rosa/sts/prereqs goes to a 404 page.

Thanks to @mike4263 for reporting this.

This is available as a community operator. External-secrets abstracts the underlying secret vaults into an ExternalSecret resource. Would be nice to have a writeup on this for those that want to deliver secrets securely to their clusters.

https://external-secrets.io/v0.7.2/

NOTE: secrets are synced from the vault to Base64-encoded K8S secrets. It should be noted that backups of the etcd database should probably be encrypted if you are to use this methodology and accept the performance penalty of the extra encryption.

This morning, I ran an accessibility crawl with Lumar, which uses axe-core as its engine. It caught a few issues, and it also lead me to manually check and catch a few more.

I'm only listing violations of WCAG 2.1 up through level AA, and not AAA or best practices.

1. The copy icon for code blocks should have 3:1 contrast from its background. This element is used at multiple pages.
   

2. A couple pages have empty links:

Observability
<a href="/experts/o11y/ocp-grafana/"></a>

Installing the Kubernetes Secret Store CSI on OpenShift
<a href="/experts/misc/secrets-store-csi/install-kubernetes-secret-store-driver/"></a>
<a href="/experts/misc/secrets-store-csi/uninstall-kubernetes-secret-store-driver/"></a>

3. Image on the Azure Front Door with ARO page needs alt attribute:
   

Also, the word "browser" was mistyped as "broswer" above the image (we've all done it!).

4. Links should not open in new windows unless 1) this is essential to the experience, and 2) the user is tipped off that this will happen. I found a few links that do this, so it could be worth searching all over the site.

For example, there's this link at the Deploying Grafana on OpenShift 4 page.

5. Lumar and I also found some issues the Tutorial: ROSA Prerequisites page, but that's hosted at docs.openshift.com. I can recheck that page, too, if you ever want to update it. It doesn't have a page language set, there are <span> elements as direct children of an <ol>, etc. That said, those might be sitewide template issues, so maybe too big to tackle for this project!

When running make preview, there is a syntax error originating from docs/aro/registry/README.md:

Liquid syntax error (line 28): [:dot, "."] is not a valid expression in "{{ .spec.host }}" in docs/aro/registry/README.md

in this document
https://cloud.redhat.com/experts/aro/azure-arc-integration/
Enable log aggregation instructions needs to be replaced by the ones seen here:

https://learn.microsoft.com/en-us/azure/azure-monitor/containers/kubernetes-monitoring-enable?tabs=cli#enable-container-insights

"

Arc-enabled cluster with ARO or OpenShift or Windows nodes

Managed identity authentication is not supported for Arc-enabled Kubernetes clusters with ARO (Azure Red Hat OpenShift) or OpenShift or Windows nodes. Use legacy authentication by specifying amalogs.useAADAuth=false as in the following example.

Azure CLI

Copy
az k8s-extension create --name azuremonitor-containers --cluster-name --resource-group --cluster-type connectedClusters --extension-type Microsoft.AzureMonitor.Containers --configuration-settings amalogs.useAADAuth=false

There seems to be typos in the following section:

https://github.com/rh-mobb/documentation/tree/main/docs/idp/azuread-aro-cli#add-servive-principal-for-the-new-app

1. Add Servive Principal for the new app
2. Create Pervice Principal for the app created:

We should create an alert shortcode that enables the automatic wrapping of the rh-alert in markdown using Hugo.