Merge branch 'main' into RHIDP-4807-main

Author: hmanwani-rh

artifacts/attributes.adoc

@@ -26,6 +26,8 @@
 :ocp-very-short: RHOCP
 :osd-brand-name: Red Hat OpenShift Dedicated
 :osd-short: OpenShift Dedicated
+:logging-brand-name: Red Hat OpenShift Logging
+:logging-short: OpenShift Logging
 // minimum and current latest supported versions
 :ocp-version-min: 4.14
 :ocp-version: 4.17

assemblies/assembly-about-rhdh.adoc

@@ -19,4 +19,4 @@ This platform is driven by a centralized software catalog, providing efficiency
 Use {product} to simplify decision-making through a selection of internally approved tools, programming languages, and developer resources within a self-managed portal.
 
 
-include::modules/discover/con-benefits-of-rhdh.adoc[leveloffset=+1]
+include::modules/about/con-benefits-of-rhdh.adoc[leveloffset=+1]

assemblies/assembly-audit-log.adoc

@@ -33,14 +33,16 @@ Audit logs are not forwarded to the internal log store by default because this d
 * For a complete list of fields that a {product-short} audit log can include, see xref:ref-audit-log-fields.adoc_{context}[]
 * For a list of scaffolder events that a {product-short} audit log can include, see xref:ref-audit-log-scaffolder-events.adoc_{context}[]
 
-include::modules/observe/con-audit-log-config.adoc[leveloffset=+1]
+include::modules/observe/con-audit-log-config.adoc[]
 
-include::modules/observe/proc-audit-log-view.adoc[leveloffset=+1]
+include::modules/observe/proc-forward-audit-log-splunk.adoc[leveloffset=+2]
+
+include::modules/observe/proc-audit-log-view.adoc[]
 
 include::modules/observe/ref-audit-log-fields.adoc[leveloffset=+2]
 
 include::modules/observe/ref-audit-log-scaffolder-events.adoc[leveloffset=+2]
 
 include::modules/observe/ref-audit-log-catalog-events.adoc[leveloffset=+2]
 
-include::modules/observe/ref-audit-log-file-rotation-overview.adoc[leveloffset=+1]
+include::modules/observe/ref-audit-log-file-rotation-overview.adoc[]

assemblies/assembly-configuring-authorization-in-rhdh.adoc

@@ -16,37 +16,32 @@ the {product-short} RBAC feature allows you
 to define policies in a declarative fashion using a simple CSV based format.
 You can define the policies by using {product-short} web interface or REST API, rather than editing the CSV directly.
 
-To apply RBAC in {product-short}:
+To define authorizations in {product-short}:
 
-. The {product-short} administrator sets up the RBAC feature:
-.. Enable the RBAC feature
-.. Configure Policy Administrators
+. The {product-short} administrator enables and gives access to the RBAC feature.
 
-. The {product-short} policy administrator configures your RBAC policies:
-.. Define roles with specific permissions
-.. Assign the roles to users and groups
+. You define your roles and policies by combining the following methods:
 
+* The {product-short} policy administrator uses the {product-short} web interface or REST API.
+* The {product-short} administrator edits the main {product-short} configuration file.
+* The {product-short} administrator edits external files.
 
 include::modules/authorization/proc-enabling-the-rbac-plugin.adoc[leveloffset=+1]
 
 
-include::assembly-managing-authorizations-by-using-the-rhdh-web-ui.adoc[leveloffset=+1]
-
+include::modules/authorization/proc-determining-permission-policy-and-role-configuration-source.adoc[leveloffset=+1]
 
-include::assembly-managing-authorizations-by-using-the-rest-api.adoc[leveloffset=+1]
 
-
-include::modules/authorization/ref-rbac-permission-policies.adoc[leveloffset=+1]
+include::assembly-managing-authorizations-by-using-the-rhdh-web-ui.adoc[leveloffset=+1]
 
 
-include::modules/authorization/con-rbac-config-permission-policies.adoc[leveloffset=+2]
+include::assembly-managing-authorizations-by-using-the-rest-api.adoc[leveloffset=+1]
 
 
-include::modules/authorization/con-rbac-config-permission-policies-external-file.adoc[leveloffset=+3]
+include::assembly-managing-authorizations-by-using-external-files.adoc[leveloffset=+1]
 
-include::modules/authorization/proc-mounting-the-policy-csv-file-using-the-operator.adoc[leveloffset=+4]
 
-include::modules/authorization/proc-mounting-the-policy-csv-file-using-helm.adoc[leveloffset=+4]
+include::modules/authorization/ref-rbac-permission-policies.adoc[leveloffset=+1]
 
 
 include::modules/authorization/con-rbac-conditional-policies-rhdh.adoc[leveloffset=+1]
@@ -55,9 +50,6 @@ include::modules/authorization/con-rbac-conditional-policies-rhdh.adoc[leveloffs
 include::modules/authorization/ref-rbac-conditional-policy-definition.adoc[leveloffset=+2]
 
 
-include::modules/authorization/proc-rbac-config-conditional-policy-file.adoc[leveloffset=+2]
-
-
 include::modules/authorization/con-user-stats-rhdh.adoc[leveloffset=+1]
 
 

assemblies/assembly-managing-authorizations-by-using-external-files.adoc

@@ -0,0 +1,10 @@
+[id='managing-authorizations-by-using-external-files']
+= Managing authorizations by using external files
+
+To automate {product} maintenance, you can configure permissions and roles in external files, before starting {product-short}.
+
+
+include::modules/authorization/proc-defining-authorizations-in-external-files-by-using-the-operator.adoc[leveloffset=+1]
+
+include::modules/authorization/proc-defining-authorizations-in-external-files-by-using-helm.adoc[leveloffset=+1]
+

assemblies/assembly-managing-authorizations-by-using-the-rhdh-web-ui.adoc

@@ -1,4 +1,4 @@
-[id='proc-rbac-ui-manage-roles_{context}']
+[id='managing-authorizations-by-using-the-web-ui']
 = Managing role-based access controls (RBAC) using the {product} Web UI
 
 Policy administrators can use the {product-short} web interface (Web UI) to allocate specific roles and permissions to individual users or groups. Allocating roles ensures that access to resources and functionalities is regulated across the {product-short}.

assemblies/assembly-rhdh-integration-aks.adoc

@@ -13,4 +13,4 @@ This integration requires the deployment of {product-short} on {aks-short} using
 * The Helm chart
 * The {product} Operator
 
-//include::modules/admin/proc-rhdh-monitoring-logging-aks.adoc[leveloffset=+1] // moving observe category related content to new titles: RHIDP-4814
+//include::modules/admin/proc-rhdh-monitoring-logging-aks.adoc[leveloffset=+1] // moving observe category related content to new titles: RHIDP-4814

assemblies/assembly-running-rhdh-behind-a-proxy.adoc

@@ -6,8 +6,9 @@ You can run the {product-very-short} application behind a corporate proxy by set
 * `HTTP_PROXY`: Denotes the proxy to use for HTTP requests.
 * `HTTPS_PROXY`: Denotes the proxy to use for HTTPS requests.
 
-Additionally, you can set the `NO_PROXY` environment variable to exclude certain domains from proxying. The variable value is a comma-separated list of hostnames that do not require a proxy to get reached, even if one is specified.
+Additionally, set the `NO_PROXY` environment variable to bypass the proxy for certain domains. The variable value is a comma-separated list of hostnames or IP addresses that can be accessed without the proxy, even if one is specified.
 
+include::modules/admin/procedure-understanding-no-proxy.adoc[leveloffset=+1]
 
 include::modules/admin/proc-configuring-proxy-in-helm-deployment.adoc[leveloffset=+1]
 include::modules/admin/proc-configuring-proxy-in-operator-deployment.adoc[leveloffset=+1]

modules/discover/con-benefits-of-rhdh.adoc renamed to modules/about/con-benefits-of-rhdh.adoc

@@ -0,0 +1,34 @@
+[id="understanding-no-proxy"]
+= Understanding the `NO_PROXY` exclusion rules
+
+`NO_PROXY` is a comma or space-separated list of hostnames or IP addresses, with optional port numbers. If the input URL matches any of the entries listed in `NO_PROXY`, a direct request fetches that URL, for example, bypassing the proxy settings.
+
+[NOTE]
+====
+The default value for `NO_PROXY` in {product-very-short} is `localhost,127.0.0.1`. If you want to override it, include at least `localhost` or `localhost:7007` in the list. Otherwise, the {product-very-short} backend might fail.
+====
+
+Matching follows the rules below:
+
+* `NO_PROXY=*` will bypass the proxy for all requests.
+
+* Space and commas might separate the entries in the `NO_PROXY` list. For example, `NO_PROXY="localhost,example.com"`, or `NO_PROXY="localhost example.com"`, or `NO_PROXY="localhost, example.com"` would have the same effect.
+
+* If `NO_PROXY` contains no entries, configuring the `HTTP(S)_PROXY` settings makes the backend send all requests through the proxy.
+
+* The backend does not perform a DNS lookup to determine if a request should bypass the proxy or not. For example, if DNS resolves `example.com` to `1.2.3.4`, setting `NO_PROXY=1.2.3.4` has no effect on requests sent to `example.com`. Only requests sent to the IP address `1.2.3.4` bypass the proxy.
+
+* If you add a port after the hostname or IP address, the request must match both the host/IP and port to bypass the proxy. For example, `NO_PROXY=example.com:1234` would bypass the proxy for requests to `http(s)://example.com:1234`, but not for requests on other ports, like `http(s)://example.com`.
+
+* If you do not specify a port after the hostname or IP address, all requests to that host/IP address will bypass the proxy regardless of the port. For example, `NO_PROXY=localhost` would bypass the proxy for requests sent to URLs like `http(s)://localhost:7077` and `http(s)://localhost:8888`.
+
+* IP Address blocks in CIDR notation will not work. So setting `NO_PROXY=10.11.0.0/16` will not have any effect, even if the backend sends a request to an IP address in that block.
+
+* Supports only IPv4 addresses. IPv6 addresses like `::1` will not work.
+
+* Generally, the proxy is only bypassed if the hostname is an exact match for an entry in the `NO_PROXY` list. The only exceptions are entries that start with a dot (`.`) or with a wildcard (`*`). In such a case, bypass the proxy if the hostname ends with the entry. 
+
+[NOTE]
+====
+List the domain and the wildcard domain if you want to exclude a given domain and all its subdomains. For example, you would set `NO_PROXY=example.com,.example.com` to bypass the proxy for requests sent to `http(s)://example.com` and `http(s)://subdomain.example.com`.
+====