Add setup-openfaas skill

[welteki]

Description

Adds a new setup-openfaas skill that installs and configures OpenFaaS into an existing Kubernetes cluster via the official faas-netes Helm chart.

The skill covers:

• OpenFaaS Community Edition (CE) — minimal Helm install for exploration and development.
• OpenFaaS Pro (Standard / For Enterprises) — production-grade install with the recommended values-pro.yaml overlay: gateway + operator with leader election, Pro autoscaler, JetStream queue-worker, dashboard, NATS, and security context.
• Standard vs For Enterprises — clarifies that both variants share the same chart and openfaasPro: true flag, with Enterprise-specific notes for multi-namespace (openfaas=1 label) and operator client rate limits.
• IAM / SSO — optional Enterprise step that creates the issuer-key, aes-key, and OIDC client-secret K8s secrets and adds the iam: / iam.dashboardIssuer: blocks to the values file. Creation of JwtIssuer, Policy, and Role CRs is flagged as a post-install task with a link to the IAM walkthrough.
• A prompt-for-missing-values rule instructing the agent to ask the user for anything it can't reasonably derive (gateway URL, OIDC client ID/secret, license path, kubeconfig, etc.) rather than guessing.

External Helm charts (event connectors, dedicated queue-workers, Pro Function Builder, OIDC proxy, external NATS) and ingress/TLS/DNS setup are explicitly out of scope for this initial version.

The README skills table is updated with the new entry.

Motivation and context

Up to now there's no canonical skill that walks an agent through installing OpenFaaS end-to-end.

How has this been tested

The skill was exercised end-to-end on two real clusters:

• Single-node k3s cluster on macOS using Slicer for Mac — agent installed OpenFaaS Pro from a clean cluster, logged in with faas-cli, and confirmed the dashboard was reachable via port-forward.
• Three-node k3s cluster on Ubuntu using Slicer — same flow with gateway.replicas: 3, queueWorker.replicas: 3, and leaderElection.enabled: true; verified all core pods reached Ready and the cluster behaved correctly under multi-replica configuration.

In addition, follow-up prompts were tested to confirm the skill is usable for ongoing operations, not just initial install. For example: asked the agent to "extend the gateway timeouts to 1h" — it edited the values file in place, ran helm upgrade with the same arguments, and the new upstreamTimeout / readTimeout / writeTimeout were applied to the gateway deployment as expected.

[reviewfn]

AI Pull Request Overview

Disclaimer: This review was generated by automated AI and may contain errors. Do not trust its outputs without human verification.

Summary

• Adds a new setup-openfaas skill (SKILL.md) that guides an AI agent through installing OpenFaaS CE and Pro via Helm.
• Updates README.md with a new table entry for the skill.
• The skill is well-structured and covers the major install paths: CE, Pro (Standard and For Enterprises), and optional IAM/SSO.
• One concrete defect: the recommended values template unconditionally sets signingKeySecret: "dashboard-jwt" while step 4B.2 (which creates that secret) is explicitly optional, creating a silent pod failure path.
• A secondary concern: the AES key for the dashboard session cookie is generated as a hex-encoded string (openssl rand -hex 16), which produces 32 ASCII characters, not 16 raw bytes. Whether this is correct depends on what the dashboard component expects.
• Password retrieval in the login step leaks the gateway password into shell history via echo -n "$PASSWORD" |.

Approval rating (1-10)

7 — useful and well-organized, but the signingKeySecret / missing-secret defect is a concrete failure path that will affect any Pro user who accepts the default values template and skips step 4B.2.

Summary per file

Summary per file

File path	Summary
README.md	Adds one-line skill entry to the skills table. No issues.
skills/setup-openfaas/SKILL.md	New 419-line skill covering CE/Pro Helm install, IAM/SSO, and upgrade guidance. Contains the issues described below.

Overall Assessment

The skill is thorough and production-aware (leader election note, NATS replication caveat, GitOps credential guidance). The structure is clear. There are two issues that will cause real failures for users following the document as written, and one minor security hygiene gap. None are difficult to fix.

Detailed Review

Detailed Review

skills/setup-openfaas/SKILL.md

---

signingKeySecret set unconditionally while the secret-creation step is optional — High

Step 4B.2, which creates the dashboard-jwt Kubernetes secret, is prefaced with:

"Skip this if the user does not want the dashboard, or accepts dev-mode auto-generated keys (sessions invalidate on dashboard restart)."

However, the values template in 4B.3 unconditionally includes:

dashboard:
  signingKeySecret: "dashboard-jwt"

If a user skips 4B.2 and deploys with these values, the dashboard pod will fail to start because the referenced secret does not exist. The note about auto-generated keys implies the chart supports omitting signingKeySecret entirely (or setting it to an empty string), but the template as written overrides that with a non-existent secret name.

Fix: Either make signingKeySecret conditional in the template (commented out by default, uncommented only when 4B.2 is executed), or change the step ordering so 4B.2 is only shown when the user has opted in to stable signing keys. At minimum, add a callout warning that the value must be removed or blanked if the secret was not created.

---

AES key format — Medium

Step 4B.4b generates the AES key with:

openssl rand -hex 16 > aes_key

-hex 16 produces 16 random bytes encoded as 32 lowercase hexadecimal ASCII characters (e.g. a3f1...). If the OpenFaaS dashboard expects a 16- or 32-byte raw key (common for AES-128/256), this will produce an incorrect key length or silently use the hex representation, which would reduce the effective key space. The correct command for a 16-byte raw key is openssl rand 16 > aes_key; for 32-byte it is openssl rand 32 > aes_key.

This cannot be verified from the diff alone; if the dashboard's key-reading code treats the secret value as raw bytes it will receive 32 bytes of ASCII hex rather than 16 bytes of entropy. Worth checking against the dashboard's aes-key handling before publishing.

---

Gateway password exposed in shell history — Low

Step 6 retrieves and passes the basic-auth password as:

PASSWORD=$(kubectl get secret -n openfaas basic-auth -o jsonpath="{.data.basic-auth-password}" | base64 --decode)
echo -n "$PASSWORD" | faas-cli login --username admin --password-stdin

The assignment stores the password in the shell variable, and echo -n "$PASSWORD" is visible in shell history and potentially in the process list. A safer one-liner that avoids the intermediate variable:

kubectl get secret -n openfaas basic-auth \
  -o jsonpath="{.data.basic-auth-password}" \
  | base64 --decode \
  | faas-cli login --username admin --password-stdin

This is a minor point in a skill aimed at initial setup, but it is easy to fix and worth correcting since the skill is likely to be used in environments where shell history is retained.

AI agent details.

Agent processing time: 1m9.774s
Environment preparation time: 9.632s
Total time from webhook: 1m22.258s