fix warnings for use case page

Signed-off-by: Grace Grimwood <[email protected]>

Author: gracegrimwood

_layouts/use-cases.html

@@ -6,15 +6,19 @@
 <div class="row justify-content-center">
     <div class="col-11 col-lg-8 card shadow gx-5 gy-5 m-lg-5">
         <div class="card-body mx-2">
-            <div class="card-title display-6 mt-3 mb-4">Use Cases</div>
+            <div class="card-title display-6 mt-3 mb-4">
+              <h1>Use Cases</h1>
+            </div>
             <div class="row g-0">
                 <div class="col-auto">
-                  {% for use_case in site.use_cases %}
-                    <div class="card-text">{{ use_case.content | toc_only }}</div>
-                  {% endfor %}
-                  {% for use_case in site.use_cases %}
-                    <div class="card-text">{{ use_case.content | markdownify | inject_anchors}}</div>
-                  {% endfor %}
+                  <div class="card-text">
+                    {% for use_case in site.use_cases %}
+                      <div class="{{ use_case.name | slugify }}-toc">{{ use_case.content | toc_only }}</div>
+                    {% endfor %}
+                    {% for use_case in site.use_cases %}
+                      <div class="{{ use_case.name | slugify }}-content">{{ use_case.content | markdownify | inject_anchors}}</div>
+                    {% endfor %}
+                  </div>
                 </div>
             </div>
         </div>

_sass/kroxylicious.scss

@@ -37,6 +37,10 @@ body {
   height: fit-content!important;
 }
 
+a {
+  color: $kroxy-dark-green;
+}
+
 .krx-content * {
   scroll-margin-top: 5rem!important;
 }

_use_cases/encryption-at-rest.markdown

@@ -2,9 +2,9 @@
 name: Encryption At Rest
 ---
 
-### Encryption At Rest
+## Encryption At Rest
 
-#### Why
+### Why do we need Encryption At Rest?
 
 Apache Kafka® does not directly support any form of encryption for data stored within a broker. This means that the contents
 of records sent to Apache Kafka are stored in the clear on the broker's disks. Anyone with sufficient access, such as a Kafka Administrator
@@ -22,7 +22,7 @@ data is now residing in the clear on the file systems of the service provider.
 |:-----------------------------------------------------------------:|
 |    *Problem: Plain text records readable by the Kafka Admins*     |
 
-##### Isn't TLS sufficient?
+#### Isn't TLS sufficient?
 
 TLS encrypts the content _in transit_.  It means that someone using a network sniffer cannot intercept what is being
 sent over the wire between the application and the Kafka Broker.  However, once the network packets arrive at the broker,
@@ -31,7 +31,7 @@ of the broker and in the clear when the data is written to the file system.
 
 TLS does not change the problem.
 
-##### Isn't storage volume encryption an answer?
+#### Isn't storage volume encryption an answer?
 
 With storage volume encryption, the contents of the volume are encrypted with a single key.  This approach provides some mitigations.
 If the storage device is stolen or the storage device hijacked and attached to an attacker's computer, the attacker won't have
@@ -43,7 +43,7 @@ to be able to read the data, including the Kafka confidential records.
 
 Storage volume encryption doesn't really solve the problem.
 
-##### Can't the applications encrypt/decrypt the data?
+#### Can't the applications encrypt/decrypt the data?
 
 It is possible for producing applications to encrypt data before sending it to Kafka, and for consuming applications to decrypt it
 again.  With this approach the brokers never possess the records in the clear and as they don't have encryption keys, they cannot
@@ -66,7 +66,7 @@ of a design flaw or bug are significant (confidentiality breach).
 Having the applications encrypt/decrypt data themselves, whilst technically feasible, is not really a tenable solution
 at the scale required for most enterprises.
 
-#### Kroxylicious Record Encryption
+### Kroxylicious Record Encryption
 
 The Kroxylicious Record Encryption feature offers a solution to the problem.  The proxy takes the responsibility
 to encrypt and decrypt the messages. In this way, the Kafka Brokers never see the plain text content of

_use_cases/schema_validation_and_enforecement.markdown

@@ -2,9 +2,9 @@
 name: Schema Validation and Enforcement
 ---
 
-### Schema Validation and Enforcement
+## Schema Validation and Enforcement
 
-#### Why
+### Why do we need Schema Validation and Enforcement?
 
 In Apache Kafka, producing applications transfer messages to consuming applications.  In order for messages to be transferred successfully
 producers and consumers need to agree on the format of the message being transferred. If there is a mismatch between the format sent
@@ -20,7 +20,7 @@ If there is only a small number of applications, perhaps all managed by the same
 informal agreements about what message format will be used on which topic.  However, as the use of Kafka grows within the organization,
 the amount of effort required to keep all the formats in agreement grows.  Mistakes, and system downtime, become inevitable.
 
-##### Schemas to the rescue
+#### Schemas to the rescue
 
 To overcome the problem, the Kafka **client** ecosystem supports _schemas_.  Schemas provide a programmatic description
 of the message format.
@@ -33,7 +33,7 @@ inflexible as it means all applications need to be redeployed every time a schem
 as the number of applications in the system grows.  To counter this challenge organizations often choose to deploy a
 *Schema Registry*. 
 
-##### Schema Registry
+#### Schema Registry
 
 The role of the  **Schema Registry**  is to maintain a library of schemas that are in-use within an organisation.
 
@@ -46,7 +46,7 @@ the registry.  This allows the consumer to decode the message.
 |:-----------------------------------------------------------------:|
 |    *Kafka applications making use of a Schema Registry*     |
 
-#### So, what's the problem?
+### So, what's the problem?
 
 If schemas are used correctly across the entire producing and consuming application estate, the potential for a
 poison message to be introduced into the system is greatly diminished.  However, the issue is that there's significant
@@ -57,7 +57,7 @@ In Kafka, **brokers** have no knowledge of format of the messages (to the broker
 have no knowledge of the schema.  The brokers cannot help us enforce that producing applications use schemas and use them
 correctly.
 
-#### Kroxylicious Record Validation
+### Kroxylicious Record Validation
 
 The Kroxylicious Record Validation Filter provides a solution to the problem. 
 
@@ -68,7 +68,7 @@ even if producing applications are misconfigured.
 
 The filter currently supports two modes of operation:
 
-1. Schema validation[^1] validates the content of the record against a schema. Use this for topics which have an entry in
+1. Schema validation[^3] validates the content of the record against a schema. Use this for topics which have an entry in
    the Schema Registry.
 2. SyntacticallyCorrectJson validation ensures the producer is producing messages that contain syntactically valid JSON.
    Use for topics which do not have registered schemas.