CTEditor-z-to-the-r: Add missing module type tags to files starting w…

contributing_to_docs/term_glossary.adoc

@@ -1,3 +1,4 @@
+:_mod-docs-content-type: ASSEMBLY
 [id="contributing-to-docs-term-glossary"]
 = OpenShift glossary of terms
 {product-author}

contributing_to_docs/tools_and_setup.adoc

@@ -1,5 +1,7 @@
+:_mod-docs-content-type: ASSEMBLY
 [id="contributing-to-docs-tools-and-setup"]
 = Install and set up the tools and software
+
 :icons:
 :toc: macro
 :toc-title:

edge_computing/ztp-sno-additional-worker-node.adoc

@@ -1,3 +1,4 @@
+:_mod-docs-content-type: ASSEMBLY
 [id="ztp-sno-additional-worker-node"]
 = Expanding {sno} clusters with {ztp}
 include::_attributes/common-attributes.adoc[]

modules/security-platform-authentication.adoc

@@ -2,6 +2,7 @@
 //
 // * security/container_security/security-platform.adoc
 
+:_mod-docs-content-type: CONCEPT 
 [id="security-platform-authentication_{context}"]
 =  Authentication and authorization
 

modules/security-platform-certificates.adoc

@@ -2,13 +2,11 @@
 //
 // * security/container_security/security-platform.adoc
 
+:_mod-docs-content-type: CONCEPT 
 [id="security-platform-certificates_{context}"]
 = Managing certificates for the platform
 
-{product-title} has multiple components within its framework that use REST-based
-HTTPS communication leveraging encryption via TLS certificates.
-{product-title}'s installer configures these certificates during
-installation. There are some primary components that generate this traffic:
+{product-title} has multiple components within its framework that use REST-based HTTPS communication leveraging encryption via TLS certificates. {product-title}'s installer configures these certificates during installation. There are some primary components that generate this traffic:
 
 * masters (API server and controllers)
 * etcd
@@ -19,6 +17,4 @@ installation. There are some primary components that generate this traffic:
 [id="security-platform-config-custom-certs_{context}"]
 == Configuring custom certificates
 
-You can configure custom serving certificates for the public hostnames of the
-API server and web console during initial installation or when redeploying
-certificates. You can also use a custom CA.
+You can configure custom serving certificates for the public hostnames of the API server and web console during initial installation or when redeploying certificates. You can also use a custom CA.

modules/security-platform-multi-tenancy.adoc

@@ -2,34 +2,21 @@
 //
 // * security/container_security/security-platform.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-platform-multi-tenancy_{context}"]
 = Isolating containers with multitenancy
 
-Multitenancy allows applications on an {product-title} cluster that are owned
-by multiple users, and run across multiple hosts and namespaces,
-to remain isolated from each other and from outside attacks.
-You obtain multitenancy by applying role-based access control (RBAC)
+Multitenancy allows applications on an {product-title} cluster that are owned by multiple users, and run across multiple hosts and namespaces,
+to remain isolated from each other and from outside attacks. You obtain multitenancy by applying role-based access control (RBAC)
 to Kubernetes namespaces.
 
-In Kubernetes, _namespaces_ are areas where applications can run
-in ways that are separate from other applications.
-{product-title} uses and extends namespaces by adding extra
-annotations, including MCS labeling in SELinux, and identifying
-these extended namespaces as _projects_. Within the scope of
-a project, users can maintain their own cluster resources,
-including service accounts, policies, constraints,
-and various other objects.
+In Kubernetes, _namespaces_ are areas where applications can run in ways that are separate from other applications. {product-title} uses and extends namespaces by adding extra annotations, including MCS labeling in SELinux, and identifying these extended namespaces as _projects_. Within the scope of a project, users can maintain their own cluster resources, including service accounts, policies, constraints, and various other objects.
 
-RBAC objects are assigned to projects to authorize selected users
-to have access to those projects. That authorization takes the form
-of rules, roles, and bindings:
+RBAC objects are assigned to projects to authorize selected users to have access to those projects. That authorization takes the form of rules, roles, and bindings:
 
-* Rules define what a user can create or access in a project.
+* Rules define what a user can create or access in a project. 
 * Roles are collections of rules that you can bind to selected users or groups.
 * Bindings define the association between users or groups and roles. 
 
-Local RBAC roles and bindings attach a user or group to a
-particular project. Cluster RBAC can attach cluster-wide roles and bindings
-to all projects in a cluster. There are default
-cluster roles that can be assigned to provide `admin`, `basic-user`, `cluster-admin`,
-and `cluster-status` access.
+Local RBAC roles and bindings attach a user or group to a particular project. Cluster RBAC can attach cluster-wide roles and bindings
+to all projects in a cluster. There are default cluster roles that can be assigned to provide `admin`, `basic-user`, `cluster-admin`, and `cluster-status` access.

modules/security-registries-ecosystem.adoc

@@ -2,40 +2,20 @@
 //
 // * security/container_security/security-registries.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-registries-ecosystem_{context}"]
 = Getting containers from Red Hat Registry and Ecosystem Catalog
 
-Red Hat lists certified container images for Red Hat products and partner offerings from the
-link:https://catalog.redhat.com/software/containers/explore[Container Images]
-section of the Red Hat Ecosystem Catalog. From that catalog,
-you can see details of each image, including CVE, software packages listings, and health
-scores.
+Red Hat lists certified container images for Red Hat products and partner offerings from the link:https://catalog.redhat.com/software/containers/explore[Container Images] section of the Red Hat Ecosystem Catalog. From that catalog, you can see details of each image, including CVE, software packages listings, and health scores.
 
-Red Hat images are actually stored in what is referred to as the _Red Hat Registry_,
-which is represented by a public container registry (`registry.access.redhat.com`)
-and an authenticated registry (`registry.redhat.io`).
-Both include basically the same set of container images, with
-`registry.redhat.io` including some additional images that require authentication
-with Red Hat subscription credentials.
+Red Hat images are actually stored in what is referred to as the _Red Hat Registry_, which is represented by a public container registry (`registry.access.redhat.com`) and an authenticated registry (`registry.redhat.io`). Both include basically the same set of container images, with
+`registry.redhat.io` including some additional images that require authentication with Red Hat subscription credentials.
 
-Container content is monitored for vulnerabilities by Red Hat and updated
-regularly. When Red Hat releases security updates, such as fixes to _glibc_,
-link:https://access.redhat.com/security/vulnerabilities/drown[DROWN], or
-link:https://access.redhat.com/blogs/766093/posts/2757141[Dirty Cow],
-any affected container images are also rebuilt and pushed
-to the Red Hat Registry.
+Container content is monitored for vulnerabilities by Red Hat and updated regularly. When Red Hat releases security updates, such as fixes to _glibc_, link:https://access.redhat.com/security/vulnerabilities/drown[DROWN], or link:https://access.redhat.com/blogs/766093/posts/2757141[Dirty Cow], any affected container images are also rebuilt and pushed to the Red Hat Registry.
 
-Red Hat uses a `health index` to reflect the security risk for each container provided through
-the Red Hat Ecosystem Catalog. Because containers consume software provided by Red
-Hat and the errata process, old, stale containers are insecure whereas new,
-fresh containers are more secure.
+Red Hat uses a `health index` to reflect the security risk for each container provided through the Red Hat Ecosystem Catalog. Because containers consume software provided by Red Hat and the errata process, old, stale containers are insecure whereas new, fresh containers are more secure.
 
-To illustrate the age of containers, the Red Hat Ecosystem Catalog uses a
-grading system. A freshness grade is a measure of the oldest and most severe
-security errata available for an image. "A" is more up to date than "F". See
-link:https://access.redhat.com/articles/2803031[Container Health Index grades as used inside the Red Hat Ecosystem Catalog] for more details on this grading system.
+To illustrate the age of containers, the Red Hat Ecosystem Catalog uses a grading system. A freshness grade is a measure of the oldest and most severe security errata available for an image. "A" is more up to date than "F". See link:https://access.redhat.com/articles/2803031[Container Health Index grades as used inside the Red Hat Ecosystem Catalog] for more details on this grading system.
 
-See the link:https://access.redhat.com/security/[Red Hat Product Security Center]
-for details on security updates and vulnerabilities related to Red Hat software.
-Check out link:https://access.redhat.com/security/security-updates/#/security-advisories[Red Hat Security Advisories]
+See the link:https://access.redhat.com/security/[Red Hat Product Security Center] for details on security updates and vulnerabilities related to Red Hat software. Check out link:https://access.redhat.com/security/security-updates/#/security-advisories[Red Hat Security Advisories]
 to search for specific advisories and CVEs.

modules/security-registries-immutable.adoc

@@ -2,27 +2,17 @@
 //
 // * security/container_security/security-registries.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-registries-immutable_{context}"]
 = Immutable and certified containers
 
-Consuming security updates is particularly important when managing _immutable
-containers_. Immutable containers are containers that will never be changed
-while running. When you deploy immutable containers, you do not step into the
-running container to replace one or more binaries. From an operational
-standpoint, you rebuild and redeploy an updated container image
-to replace a container instead of changing it.
+Consuming security updates is particularly important when managing _immutable containers_. Immutable containers are containers that will never be changed while running. When you deploy immutable containers, you do not step into the running container to replace one or more binaries. From an operational standpoint, you rebuild and redeploy an updated container image to replace a container instead of changing it.
 
 Red Hat certified images are:
 
 * Free of known vulnerabilities in the platform components or layers
 * Compatible across the {op-system-base} platforms, from bare metal to cloud
 * Supported by Red Hat
 
-The list of known vulnerabilities is constantly evolving, so you must track the
-contents of your deployed container images, as well as newly downloaded images,
-over time. You can use
-link:https://access.redhat.com/security/security-updates/#/security-advisories[Red Hat Security Advisories (RHSAs)]
-to alert you to any newly discovered issues in
-Red Hat certified container images, and direct you to the updated image.
-Alternatively, you can go to the Red Hat Ecosystem Catalog
-to look up that and other security-related issues for each Red Hat image.
+The list of known vulnerabilities is constantly evolving, so you must track the contents of your deployed container images, as well as newly downloaded images, over time. You can use link:https://access.redhat.com/security/security-updates/#/security-advisories[Red Hat Security Advisories (RHSAs)] to alert you to any newly discovered issues in Red Hat certified container images, and direct you to the updated image.
+Alternatively, you can go to the Red Hat Ecosystem Catalog to look up that and other security-related issues for each Red Hat image.

modules/security-registries-openshift.adoc

@@ -2,13 +2,10 @@
 //
 // * security/container_security/security-registries.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-registries-openshift_{context}"]
 = OpenShift Container Registry
 
-{product-title} includes the _OpenShift Container Registry_, a private registry
-running as an integrated component of the platform that you can use to manage your container
-images. The OpenShift Container Registry provides role-based access controls
-that allow you to manage who can pull and push which container images.
+{product-title} includes the _OpenShift Container Registry_, a private registry running as an integrated component of the platform that you can use to manage your container images. The OpenShift Container Registry provides role-based access controls that allow you to manage who can pull and push which container images.
 
-{product-title} also supports integration with other private registries that you might
-already be using, such as {quay}.
+{product-title} also supports integration with other private registries that you might already be using, such as {quay}.

modules/security-registries-quay.adoc

@@ -2,8 +2,10 @@
 //
 // * security/container_security/security-registries.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-registries-quay_{context}"]
 = Storing containers using {quay}
+
 link:https://access.redhat.com/products/red-hat-quay[{quay}] is an
 enterprise-quality container registry product from Red Hat.
 Development for {quay} is done through the upstream

modules/security-registries-where.adoc

@@ -2,10 +2,8 @@
 //
 // * security/container_security/security-registries.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-registries-where_{context}"]
 = Knowing where containers come from?
 
-There are tools you can use to scan and track the contents of your downloaded
-and deployed container images. However, there are many public sources of
-container images. When using public container registries, you can add a layer of
-protection by using trusted sources.
+There are tools you can use to scan and track the contents of your downloaded and deployed container images. However, there are many public sources of container images. When using public container registries, you can add a layer of protection by using trusted sources.

modules/security-storage-block.adoc

@@ -2,10 +2,8 @@
 //
 // * security/container_security/security-storage.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-network-storage-block_{context}"]
 = Block storage
 
-For block storage providers like AWS Elastic Block Store (EBS), GCE Persistent
-Disks, and iSCSI, {product-title} uses SELinux capabilities to secure the root
-of the mounted volume for non-privileged pods, making the mounted volume owned
-by and only visible to the container with which it is associated.
+For block storage providers like AWS Elastic Block Store (EBS), GCE Persistent Disks, and iSCSI, {product-title} uses SELinux capabilities to secure the root of the mounted volume for non-privileged pods, making the mounted volume owned by and only visible to the container with which it is associated.

modules/security-storage-persistent.adoc

@@ -2,6 +2,7 @@
 //
 // * security/container_security/security-storage.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-network-storage-persistent_{context}"]
 =  Persistent volume plugins
 

modules/security-storage-shared.adoc

@@ -2,10 +2,9 @@
 //
 // * security/container_security/security-storage.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-network-storage-shared_{context}"]
 = Shared storage
 
 For shared storage providers like NFS, the PV registers its
-group ID (GID) as an annotation on the PV resource. Then, when the PV is claimed
-by the pod, the annotated GID is added to the supplemental groups of the pod,
-giving that pod access to the contents of the shared storage.
+group ID (GID) as an annotation on the PV resource. Then, when the PV is claimed by the pod, the annotated GID is added to the supplemental groups of the pod, giving that pod access to the contents of the shared storage.

modules/security-understanding-containers.adoc

@@ -2,6 +2,7 @@
 //
 // * security/container_security/security-understanding.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-understanding-containers_{context}"]
 = What are containers?
 

modules/security-understanding-openshift.adoc

@@ -2,28 +2,19 @@
 //
 // * security/container_security/security-understanding.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="security-understanding-openshift_{context}"]
 = What is {product-title}?
 
-Automating how containerized applications are deployed, run, and managed is the
-job of a platform such as {product-title}. At its core, {product-title} relies
-on the Kubernetes project to provide the engine for orchestrating containers
+Automating how containerized applications are deployed, run, and managed is the job of a platform such as {product-title}. At its core, {product-title} relies on the Kubernetes project to provide the engine for orchestrating containers
 across many nodes in scalable data centers.
 
-Kubernetes is a project, which can run using different operating systems
-and add-on components that offer no guarantees of supportability from the project.
-As a result, the security of different Kubernetes platforms can vary.
+Kubernetes is a project, which can run using different operating systems and add-on components that offer no guarantees of supportability from the project. As a result, the security of different Kubernetes platforms can vary.
 
-{product-title} is designed to lock down Kubernetes security and integrate
-the platform with a variety of extended components. To do this,
-{product-title} draws on the extensive Red Hat ecosystem of open source
-technologies that include the operating systems, authentication, storage,
-networking, development tools, base container images, and many other
-components.
+{product-title} is designed to lock down Kubernetes security and integrate the platform with a variety of extended components. To do this,
+{product-title} draws on the extensive Red Hat ecosystem of open source technologies that include the operating systems, authentication, storage,
+networking, development tools, base container images, and many other components.
 
-{product-title} can leverage Red Hat's experience in uncovering
-and rapidly deploying fixes for vulnerabilities in the platform itself
-as well as the containerized applications running on the platform.
-Red Hat's experience also extends to efficiently integrating new
-components with {product-title} as they become available and
-adapting technologies to individual customer needs.
+{product-title} can leverage Red Hat's experience in uncovering and rapidly deploying fixes for vulnerabilities in the platform itself
+as well as the containerized applications running on the platform. Red Hat's experience also extends to efficiently integrating new
+components with {product-title} as they become available and adapting technologies to individual customer needs.

modules/serverless-services-network-policies.adoc

@@ -2,7 +2,7 @@
 //
 // * serverless/knative-serving/config-applications/restrictive-cluster-policies.adoc
 
-:_mod-docs-content-type: Concept
+:_mod-docs-content-type: CONCEPT
 [id="serverless-services-network-policies_{context}"]
 = Clusters with restrictive network policies
 

modules/service-accounts-as-oauth-clients.adoc

@@ -2,6 +2,7 @@
 //
 // * authentication/using-service-accounts-as-oauth-client.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id="service-accounts-as-oauth-clients_{context}"]
 = Service accounts as OAuth clients
 

modules/service-accounts-default.adoc

@@ -2,6 +2,7 @@
 //
 // * authentication/using-service-accounts.adoc
 
+:_mod-docs-content-type: REFERENCE
 [id="service-accounts-default_{context}"]
 = Default service accounts
 

modules/service-accounts-granting-roles.adoc

@@ -2,6 +2,7 @@
 //
 // * authentication/using-service-accounts.adoc
 
+:_mod-docs-content-type: REFERENCE
 [id="service-accounts-granting-roles_{context}"]
 = Granting roles to service accounts
 

modules/storage-ephemeral-storage-manage.adoc

@@ -4,6 +4,7 @@
 //* storage/understanding-ephemeral-storage.adoc
 //* microshift_storage/understanding-ephemeral-storage-microshift.adoc
 
+:_mod-docs-content-type: CONCEPT
 [id=storage-ephemeral-storage-manage_{context}]
 = Ephemeral storage management
 

modules/storage-ephemeral-storage-monitoring.adoc

@@ -3,7 +3,7 @@
 // storage/understanding-persistent-storage.adoc[leveloffset=+1]
 //* microshift_storage/understanding-ephemeral-storage-microshift.adoc
 
-
+:_mod-docs-content-type: REFERENCE
 [id=storage-ephemeral-storage-monitoring_{context}]
 = Monitoring ephemeral storage