Helm chart component inconsistent with Helm CLI deployment

[rjferguson21]

Environment

Device and OS: Arch Linux
App version: 0.27.1
Kubernetes distro being used: k3d/k3s

Steps to reproduce

1. Create a values.yaml containing:

secrets:
  realm:
    stringData:
      realm.json: '{{ .Files.Get "resources/dev/baby-yoda.json" }}'

2. Create a zarf.yaml that has a component using P1's Keycloak chart and the values.yaml

kind: ZarfPackageConfig
metadata:
  name: keycloak-test
  description: "Test"
  version: "0.1"
  architecture: amd64 

components:
  - name: keycloak
    required: true
    charts:
      - name: keycloak
        version: 18.4.3-bb.0
        namespace: keycloak
        url: https://repo1.dso.mil/big-bang/product/packages/keycloak.git
        gitPath: chart
        valuesFiles:
          - values.yaml
    images:
      - registry1.dso.mil/ironbank/opensource/keycloak/keycloak:21.1.1
      - registry1.dso.mil/ironbank/opensource/postgres/postgresql12:12.14
      - registry1.dso.mil/ironbank/big-bang/p1-keycloak-plugin:3.2.1

3. Deploy to a cluster

k3d cluster create
zarf init --components=git-server --confirm
zarf package deploy --confirm zarf-package-keycloak-test-amd64-0.1.tar.zst

Expected result

The Keycloak chart will be deployed, creating the keycloak-realm secret in the keycloak namespace that contains the contents of this file in the realm.json key.

For comparison, I would expect the secret (and the rest of the Helm chart) to match a similarly configured Helm install using the same chart and values via this command:

helm upgrade --install keycloak oci://registry1.dso.mil/bigbang/keycloak --version 18.4.3-bb.0 --values values.yaml

Actual Result

The keycloak-realm secret is created but does not contain the file contents. Also of note, the Helm release as part of the the zarf package deploy succeeds but is does not actually deploy resources like the Keycloak StatefulSet

Visual Proof (screenshots, videos, text, etc)

From the zarf deployed Keycloak component: (Nothing besides secrets)

(⎈|k3d-k3s-default:default) keycloak (18.4.3-bb.0) ✗ kubectl get all -n keycloak
No resources found in keycloak namespace.
(⎈|k3d-k3s-default:default) keycloak (18.4.3-bb.0) ✗ kubectl get secrets -n keycloak
NAME                             TYPE                             DATA   AGE
private-registry                 kubernetes.io/dockerconfigjson   1      23m
private-git-server               Opaque                           2      23m
keycloak-postgresql              Opaque                           2      23m
keycloak-realm                   Opaque                           0      23m
keycloak-env                     Opaque                           4      23m
sh.helm.release.v1.keycloak.v1   helm.sh/release.v1               1      23m

From the Helm CLI deployed keycloak (notice the StatefulSet and Services)

(⎈|k3d-k3s-default:default) keycloak (18.4.3-bb.0) ✗ kubectl get all
NAME                        READY   STATUS                  RESTARTS   AGE
pod/keycloak-postgresql-0   0/1     ImagePullBackOff        0          21m
pod/keycloak-0              0/1     Init:ImagePullBackOff   0          21m

NAME                                   TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)           AGE
service/kubernetes                     ClusterIP   10.43.0.1      <none>        443/TCP           39m
service/keycloak-postgresql-headless   ClusterIP   None           <none>        5432/TCP          21m
service/keycloak-headless              ClusterIP   None           <none>        80/TCP            21m
service/keycloak-http                  ClusterIP   10.43.26.145   <none>        80/TCP,8443/TCP   21m
service/keycloak-postgresql            ClusterIP   10.43.168.33   <none>        5432/TCP          21m

NAME                                   READY   AGE
statefulset.apps/keycloak-postgresql   0/1     21m
statefulset.apps/keycloak              0/1     21m
(⎈|k3d-k3s-default:default) keycloak (18.4.3-bb.0) ✗ kubectl get secrets
NAME                             TYPE                 DATA   AGE
keycloak-env                     Opaque               4      21m
keycloak-postgresql              Opaque               2      21m
keycloak-realm                   Opaque               1      21m
sh.helm.release.v1.keycloak.v1   helm.sh/release.v1   1      21m

Severity/Priority

Additional Context

I was working from the oft recommended values.yaml from https://repo1.dso.mil/big-bang/bigbang/-/blob/master/docs/assets/configs/example/keycloak-dev-values.yaml#L84-100 to take advantage of some of these files contained in the Helm chart for templating.

[rjferguson21]

Also of note here - it appears to be something something specifically related to the baby-yoda.json file. If I point that secret to some other arbitrary file like baby-yoda.yaml the secret is created successfully with the baby-yoda.yaml file contents:

secrets:
  realm:
    stringData:
      realm.json: '{{ .Files.Get "resources/dev/baby-yoda.yaml" }}' 

I am sensitive to the fact that it feels like a random Helm templating issue but I thought I'd report because I cannot reproduce similar issues outside of Zarf.

[rjferguson21]

Testing this a bit more, it seems like I am running into some sort of size boundary. I created this example repo with a simple helm chart that deploys the same local helm chart twice with the secret template of:

apiVersion: v1
kind: Secret
metadata:
  name: example-secret
type: "Opaque"
data:
  file: {{ .Files.Get .Values.file | b64enc }}

Using https://github.com/rjferguson21/zarf-secrets/blob/main/foo/files/works.json as my file, everything works. If I use https://github.com/rjferguson21/zarf-secrets/blob/main/foo/files/fails.json, the secret is created but does not contain the file contents.

The difference between the two files:

(⎈|k3d-k3s-default:default) keycloak-zarf (main) diff foo/files/fails.json foo/files/works.json
1540,1573d1539
<     },
<     {
<       "id": "3b482c5b-59c5-4786-88f8-09123324d74d",
<       "alias": "direct grant",
<       "description": "OpenID Connect Resource Owner Grant",
<       "providerId": "basic-flow",
<       "topLevel": true,
<       "builtIn": true,
<       "authenticationExecutions": [
<         {
<           "authenticator": "direct-grant-validate-username",
<           "authenticatorFlow": false,
<           "requirement": "REQUIRED",
<           "priority": 10,
<           "userSetupAllowed": false,
<           "autheticatorFlow": false
<         },
<         {
<           "authenticator": "direct-grant-validate-password",
<           "authenticatorFlow": false,
<           "requirement": "REQUIRED",
<           "priority": 20,
<           "userSetupAllowed": false,
<           "autheticatorFlow": false
<         },
<         {
<           "authenticatorFlow": true,
<           "requirement": "CONDITIONAL",
<           "priority": 30,
<           "flowAlias": "Direct Grant - Conditional OTP",
<           "userSetupAllowed": false,
<           "autheticatorFlow": true
<         }
<       ]

I started with the original problem child (baby-yoda.json) and deleted sections until it started working and then created the two example files to illustrate that removing some arbitrary content seems to succeed.