Scaffold basic workshop frontend.

2023-12-04 14:02:37 +13:00
parent f7c9392f1c
commit 89ea336647
80 changed files with 27173 additions and 0 deletions
--- a/data/authors/default.md
+++ b/data/authors/default.md
@ -0,0 +1,8 @@
+name: Red Hat
+avatar: /static/images/redhat.png
+occupation: TSSC Workshop
+company: Open Source
+email: redhat@redhat.com
+twitter: https://twitter.com/RedHat
+github: https://github.com/RedHat
+linkedin: https://www.linkedin.com/in/RedHat
--- a/data/authors/sparrowhawk.md
+++ b/data/authors/sparrowhawk.md
@ -0,0 +1,12 @@
+---
+name: Sparrow Hawk
+avatar: /static/images/sparrowhawk-avatar.jpg
+occupation: Wizard of Earthsea
+company: Earthsea
+twitter: https://twitter.com/sparrowhawk
+linkedin: https://www.linkedin.com/sparrowhawk
+---
+
+At birth Ged was given the child-name Duny by his mother. He was born on the island of Gont, son of a bronzesmith. His mother died before he reached the age of one. As a small boy, Ged had overheard the village witch, his maternal aunt, using various words of power to call goats. Ged later used the words without understanding of their meanings, to surprising effect.
+
+The witch knew that using words of power effectively without understanding them required innate power, so she endeavored to teach him what little she knew. After learning more from her, he was able to call animals to him. Particularly, he was seen in the company of wild sparrowhawks so often that his "use name" became Sparrowhawk.
--- a/data/blog/.gitignore
+++ b/data/blog/.gitignore
--- a/data/headerNavLinks.js
+++ b/data/headerNavLinks.js
@ -0,0 +1,6 @@
+const headerNavLinks = [
+  { href: '/workshop', title: 'Exercises' },
+  { href: 'https://etherpad.wikimedia.org/p/tssc-workshop-bne-dec-23', title: 'Etherpad'}
+]
+
+export default headerNavLinks
--- a/data/logo.svg
+++ b/data/logo.svg
@ -0,0 +1,19 @@
+<?xml version="1.0" encoding="utf-8" standalone="no"?>
+<!-- Generator: Adobe Illustrator 23.0.1, SVG Export Plug-In . SVG Version: 6.00 Build 0)  -->
+<svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px"
+	 viewBox="0 0 228 228" width="39" height="30" style="enable-background:new 0 0 228 228;" xml:space="preserve">
+<style type="text/css">
+	.st0{fill:#EE0000;}
+</style>
+<g>
+	<g>
+		<path d="M187.9,100.6c0.3,1.3,0.4,2.7,0.4,4.1c0,17.7-21.5,20.7-36.3,20.7c-57.8,0-100.8-35.9-100.8-46.8c0-0.7,0-1.5,0.3-2.3
+			L47,87c-1,2.3-1.8,5.4-1.8,8.7c0,21.5,48.6,54,104.2,54c24.6,0,43.3-9.2,43.3-25.9c0-1.3,0-2.3-2-12L187.9,100.6z"/>
+		<path class="st0" d="M151.9,125.4c14.8,0,36.3-3.1,36.3-20.7c0-1.4,0-2.7-0.4-4.1l-8.8-38.4c-2.1-8.4-3.8-12.3-18.7-19.7
+			c-11.5-5.9-36.6-15.6-44-15.6c-6.9,0-9,9-17.1,9c-7.9,0-13.8-6.7-21.2-6.7c-7.2,0-11.8,4.9-15.4,14.8c0,0-10,28.2-11.3,32.2
+			c-0.3,0.8-0.3,1.6-0.3,2.3C51.1,89.5,94.2,125.4,151.9,125.4 M190.6,111.9c2,9.7,2,10.7,2,12c0,16.6-18.7,25.9-43.3,25.9
+			c-55.5,0-104.2-32.5-104.2-54c0-3.3,0.8-6.4,1.8-8.7c-20,1-45.8,4.6-45.8,27.4c0,37.4,88.6,83.4,158.7,83.4
+			c53.8,0,67.3-24.3,67.3-43.5C227.2,139.3,214.1,122.1,190.6,111.9"/>
+	</g>
+</g>
+</svg>
--- a/data/projectsData.js
+++ b/data/projectsData.js
@ -0,0 +1,11 @@
+const projectsData = [
+  {
+    title: 'BBQ and Kubernetes deployments',
+    description: `Who knew that BBQing had so much to do with deploying containers
+    to Kubernetes clusters?`,
+    imgSrc: '/static/images/google.png',
+    href: '/workshop/bbq-and-kubernetes',
+  },
+]
+
+export default projectsData
--- a/data/siteMetadata.js
+++ b/data/siteMetadata.js
@ -0,0 +1,69 @@
+const siteMetadata = {
+  title: 'Red Hat OpenShift Application Delivery Workshop',
+  author: 'Red Hat',
+  headerTitle: 'Red Hat',
+  description: 'Red Hat OpenShift Application Delivery Workshop',
+  language: 'en-us',
+  siteUrl: 'https://oadw.rhdemo.win',
+  siteRepo: 'https://github.com/jmhbnz/ocp-app-delivery-workshop',
+  siteLogo: '/static/images/redhat.png',
+  image: '/static/images/avatar.png',
+  socialBanner: '/static/images/twitter-card.png',
+  email: 'jablair@redhat.com',
+  github: 'https://github.com/jmhbnz',
+  twitter: 'https://twitter.com/redhat',
+  facebook: 'https://facebook.com',
+  youtube: 'https://www.youtube.com',
+  linkedin: 'https://www.linkedin.com',
+  locale: 'en-US',
+  analytics: {
+    // supports plausible, simpleAnalytics or googleAnalytics
+    plausibleDataDomain: '', // e.g. tailwind-nextjs-starter-blog.vercel.app
+    simpleAnalytics: false, // true or false
+    googleAnalyticsId: '', // e.g. UA-000000-2 or G-XXXXXXX
+  },
+  comment: {
+    // Select a provider and use the environment variables associated to it
+    // https://vercel.com/docs/environment-variables
+    provider: 'giscus', // supported providers: giscus, utterances, disqus
+    giscusConfig: {
+      // Visit the link below, and follow the steps in the 'configuration' section
+      // https://giscus.app/
+      repo: process.env.NEXT_PUBLIC_GISCUS_REPO,
+      repositoryId: process.env.NEXT_PUBLIC_GISCUS_REPOSITORY_ID,
+      category: process.env.NEXT_PUBLIC_GISCUS_CATEGORY,
+      categoryId: process.env.NEXT_PUBLIC_GISCUS_CATEGORY_ID,
+      mapping: 'pathname', // supported options: pathname, url, title
+      reactions: '1', // Emoji reactions: 1 = enable / 0 = disable
+      // Send discussion metadata periodically to the parent window: 1 = enable / 0 = disable
+      metadata: '0',
+      // theme example: light, dark, dark_dimmed, dark_high_contrast
+      // transparent_dark, preferred_color_scheme, custom
+      theme: 'light',
+      // theme when dark mode
+      darkTheme: 'transparent_dark',
+      // If the theme option above is set to 'custom`
+      // please provide a link below to your custom theme css file.
+      // example: https://giscus.app/themes/custom_example.css
+      //themeURL: '',
+    },
+    utterancesConfig: {
+      // Visit the link below, and follow the steps in the 'configuration' section
+      // https://utteranc.es/
+      repo: process.env.NEXT_PUBLIC_UTTERANCES_REPO,
+      issueTerm: '', // supported options: pathname, url, title
+      label: '', // label (optional): Comment 💬
+      // theme example: github-light, github-dark, preferred-color-scheme
+      // github-dark-orange, icy-dark, dark-blue, photon-dark, boxy-light
+      theme: '',
+      // theme when dark mode
+      darkTheme: '',
+    },
+    disqus: {
+      // https://help.disqus.com/en/articles/1717111-what-s-a-shortname
+      //shortname: process.env.NEXT_PUBLIC_DISQUS_SHORTNAME,
+    },
+  }
+}
+
+module.exports = siteMetadata
--- a/data/workshop/exercise1.mdx
+++ b/data/workshop/exercise1.mdx
@ -0,0 +1,189 @@
+---
+title: Getting familiar with OpenShift application platform
+exercise: 1
+date: '2023-12-04'
+tags: ['openshift','containers','kubernetes']
+draft: false
+authors: ['default']
+summary: "In this first exercise we'll get familiar with OpenShift."
+---
+
+In this first exercise we'll sign a container image using Sigstore. Specifically in this example, we're going to use "keyless" signing, one of the workflows supported by Sigstore.
+
+Sigstore keyless signing associates identities, rather than keys, with an artifact signature. The Sigstore 'Fulcio' service issues short-lived certificates binding an ephemeral key to an OpenID Connect identity. Signing events are logged in Rekor, a signature transparency log, providing an auditable record of when a signature was created.
+
+Sigstore’s root of trust, which includes Fulcio’s root CA certificate and Rekor’s public key, are distributed by The Update Framework (TUF). TUF is a framework to provide secure software and file updates. TUF defines a set of protocols to protect against various types of attacks.
+
+This "keyless" signing workflow provides a number of benefits:
+- There is no need for users to store and protect private keys used during signing. The Fulcio service destroys the private key  shortly after and the short-lived identity certificate expires. Users who wish to verify the software will use the transparency log entry, rather than relying on the signer to store and manage the private key.
+- The signature transparency log provides a complete audit trail of signature actions.
+
+Let's get started!
+
+## Lab environment
+Navigate to your project and find the `tssc-terminal` container. Create a terminal session within OpenShift:
+
+<Zoom>
+![terminal](/static/images/terminal.png)
+</Zoom>
+
+Login to the registry using your lab credentials:
+```bash
+podman login -u tssc -p $(oc whoami -t) registry.blueradish.net
+```
+Set the project for your username:
+```
+oc project userX
+```
+Pull down the test app, and re-tag it using your OpenShift project:
+```bash
+OC_PROJECT=$(oc project -q) 
+
+podman pull \
+  quay.io/smileyfritz/demo-app:v0.1.1
+
+podman tag \
+  quay.io/smileyfritz/demo-app:v0.1.1 \
+  registry.blueradish.net/$OC_PROJECT/demo-app:v1
+
+podman push \
+  registry.blueradish.net/$OC_PROJECT/demo-app:v1
+```
+
+## Sign the container image
+Firstly, grab the digest for your new image:
+```bash
+OC_PROJECT=$(oc project -q)
+
+IMAGE_REF=registry.blueradish.net/$OC_PROJECT/demo-app
+
+IMAGE_DIGEST=$(crane digest $IMAGE_REF:v1)
+```
+Now sign the container with cosign:
+```bash
+cosign sign $IMAGE_REF@$IMAGE_DIGEST
+```
+You'll be presented with a screen to authenticate Sigstore:
+
+<Zoom>
+![Sigstore auth](/static/images/exercise1/code1.png)
+</Zoom>
+
+Copy the `oauth2.sigstore.dev` link into your browser. Log into Sigstore with GitHub.
+
+<Zoom>
+![Sigstore auth 2](/static/images/exercise1/code2.png)
+</Zoom>
+
+Copy the code and paste it back into your OpenShift terminal session. The Sigstore signing action will continue, and the transparency log will be updated.
+
+<Zoom>
+![Sigstore auth 3](/static/images/exercise1/code3.png)
+</Zoom>
+
+Note the tlog entry that is created:
+```
+tlog entry created with index: 35809256
+```
+Use `crane` to list the registry contents, and verify that you have a signature created in the registry:
+```bash
+OC_PROJECT=$(oc project -q)
+
+crane ls \
+  registry.blueradish.net/$OC_PROJECT/demo-app
+```
+You should see a tag and the signature file are now created:
+```
+sha256-5e350542cb6501b78549701996fc8d22e86d9a8bc51434092d35698d0073b667.sig
+v1
+```
+
+## Verifying the signature
+We can also use the `cosign` to verify container signatures. You can do this knowing the identity that was used to sign the container as well as the certificate issuer. For example, we can validate our upstream image by running:
+```
+cosign verify --certificate-identity shane.boulden@gmail.com --certificate-oidc-issuer https://github.com/login/oauth quay.io/smileyfritz/demo-app:v0.1.1
+
+Verification for quay.io/smileyfritz/demo-app:v0.1.1 --
+The following checks were performed on each of these signatures:
+  - The cosign claims were validated
+  - Existence of the claims in the transparency log was verified offline
+  - The code-signing certificate was verified using trusted certificate authority certificates
+
+[{"critical":{"identity":{"docker-reference":"quay.io/smileyfritz/demo-app"},"image":{"docker-manifest-digest":"sha256:63c1117db19d56296150993c4f4eb78d54b386cbf35f4a2116b821e6b34ed53e"},"type":"cosign container image signature"},
+...
+```
+Now lets use the `cosign` to verify the signature you created:
+```bash
+OC_PROJECT=$(oc project -q)
+
+ cosign verify \
+   --certificate-oidc-issuer https://github.com/login/oauth \
+   --certificate-identity <your-github-identity> \
+   registry.blueradish.net/$OC_PROJECT/demo-app:v1
+```
+
+## Inspecting the transparency log
+We can also inspect the information that's been published to the Rekor transparency log, using the `tlog` entry number that was recorded initially. If you don't have one, just sign the image again with `cosign`.
+
+Let's see what the record looks like:
+```json
+rekor-cli get --log-index 35809256
+
+LogID: c0d23d6ad406973f9559f3ba2d1ca01f84147d8ffc5b8445c224f98b9591801d
+Index: 35809256
+IntegratedTime: 2023-09-12T06:03:46Z
+UUID: 24296fb24b8ad77a8b3ac548fc64ce4da8544381d36c2176cf84975da85aa05ee9e92efea91224a7
+Body: {
+  "HashedRekordObj": {
+    "data": {
+      "hash": {
+        "algorithm": "sha256",
+        "value": "628a902b63f6224376503e7169af80a2f03f522734b42e0dd768440b0359bfd0"
+      }
+    },
+    "signature": {
+      "content": "MEUCIAEdOaVgD3xzYiX9yibIU2vr2fAa3dpZzZ6fZAEJOwa7AiEA2204D/Pg91BLRVtqR9t0DQpEivbrxwuJ3zhEjdDvJ3U=",
+      "publicKey": {
+        "content": "LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMxekNDQWwyZ0F3SUJBZ0lVVGE0eHh1b1dadjNlcTBVbTQ5Nm9xQmhXeStJd0NnWUlLb1pJemowRUF3TXcKTnpFVk1CTUdBMVVFQ2hNTWMybG5jM1J2Y21VdVpHVjJNUjR3SEFZRFZRUURFeFZ6YVdkemRHOXlaUzFwYm5SbApjbTFsWkdsaGRHVXdIaGNOTWpNd09URXlNRFl3TXpReldoY05Nak13T1RFeU1EWXhNelF6V2pBQU1Ga3dFd1lICktvWkl6ajBDQVFZSUtvWkl6ajBEQVFjRFFnQUV1dG5mRmpHNFZ3MnUxNFBOVjJ4OFQrL1pRUGZNVVhWS0tSMWcKU2RhTml3bzllQ2FMdlNrRk10b2RlRGdjM3JHa2NLV09BbGJOUktKdThvOWFnWFN0MXFPQ0FYd3dnZ0Y0TUE0RwpBMVVkRHdFQi93UUVBd0lIZ0RBVEJnTlZIU1VFRERBS0JnZ3JCZ0VGQlFjREF6QWRCZ05WSFE0RUZnUVVFdmoyClhaOFZQU0R5ZmFtRkIyT0poTlQyMUJvd0h3WURWUjBqQkJnd0ZvQVUzOVBwejFZa0VaYjVxTmpwS0ZXaXhpNFkKWkQ4d0pRWURWUjBSQVFIL0JCc3dHWUVYYzJoaGJtVXVZbTkxYkdSbGJrQm5iV0ZwYkM1amIyMHdMQVlLS3dZQgpCQUdEdnpBQkFRUWVhSFIwY0hNNkx5OW5hWFJvZFdJdVkyOXRMMnh2WjJsdUwyOWhkWFJvTUM0R0Npc0dBUVFCCmc3OHdBUWdFSUF3ZWFIUjBjSE02THk5bmFYUm9kV0l1WTI5dEwyeHZaMmx1TDI5aGRYUm9NSUdMQmdvckJnRUUKQWRaNUFnUUNCSDBFZXdCNUFIY0EzVDB3YXNiSEVUSmpHUjRjbVdjM0FxSktYcmplUEszL2g0cHlnQzhwN280QQpBQUdLaC8wUlFnQUFCQU1BU0RCR0FpRUFreDNqVHJxMXplcFpaQm5wUjlzL1ZDRzcyU2hCVW5nQTVCeitDd21nCnJrUUNJUUNxYnRqaVFkMndxNE5NTmkvOG0ycXVNVlVrQ2tXMDVEVGR3RHIvNDljZTh6QUtCZ2dxaGtqT1BRUUQKQXdOb0FEQmxBakVBay9TZ0pOcmpXc1B3WXl2bTBNNnVMMFQwSVVuVjlPeE1WRDQyTjh0M09wTTNGdUZHR3lyNgpkR2crYVpOQ25zdXRBakEyTGpicjN4UHIrdDloa2VadG9lZFhWM2VJeTJPdmdERnJRbUI1dFFwNEJyajZjZHdOCmRsUXN0b2dHdkdVZ0lqRT0KLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQo="
+      }
+    }
+  }
+}
+```
+Since this is a json document we can extract the information with `jq`. For example, we can look at the certificates that were generated by Cosign and signed by the Fulcio CA:
+```bash
+# Fetch the record from Rekor by log index in JSON format
+REKOR_RECORD=$(rekor-cli get --log-index 35809256 --format json)
+
+# Extract the public key content from the Rekor record using jq
+PUBLIC_KEY=$(echo "$REKOR_RECORD" |\
+ jq -r '.Body.HashedRekordObj.signature.publicKey.content')
+
+# Decode the base64-encoded content of the public key
+DECODED_KEY=$(echo "$PUBLIC_KEY" | base64 -d)
+
+# Display the X.509 certificate information of the decoded key
+openssl x509 -noout -text <<< "$DECODED_KEY"
+```
+```yaml
+
+Certificate:
+    Data:
+        Version: 3 (0x2)
+        Serial Number:
+            4d:ae:31:c6:ea:16:66:fd:de:ab:45:26:e3:de:a8:a8:18:56:cb:e2
+        Signature Algorithm: ecdsa-with-SHA384
+        Issuer: O = sigstore.dev, CN = sigstore-intermediate
+        Validity
+            Not Before: Sep 12 06:03:43 2023 GMT
+            Not After : Sep 12 06:13:43 2023 GMT
+        Subject: 
+        Subject Public Key Info:
+            Public Key Algorithm: id-ecPublicKey
+                Public-Key: (256 bit)
+```
+## Stretch goals
+Let's investigate data stored in Rekor. See if you can use the `rekor-cli` commands to find out more about the image `cgr.dev/chainguard/jre:latest`:
+- Which version of `openssl-config` is used in this image?
+- How was this image signed? Was it interactively signed, or was a build system used?
+- When was this image last signed?