CRC16 in Helm

I needed a CRC16 checksum implementation in Helm. This is not code I would have written before - it felt frivolous, not a good use of my time. But Claude Code gave me a working implementation with tests in one shot.

You might think this is another waste of valuable compute on a frivolous activity. Far from it - this implementation is driven by necessity and it simplifies our stack.

The backstory

When GKE released Workload Identity in 2020, I built a Kubernetes operator in Go. It would recognise a label on a ServiceAccount, create the corresponding Config Connector resources, and wire up the Kubernetes-to-GCP identity binding automatically.

It worked. It improved our security posture and eliminated an entire class of future problems - the kind where someone creates a JSON key “just to test something” and that key ends up in a git history, a Slack message, or worse.

As of today, that operator has prevented at least 1,484 JSON keys from being created. Four new identities were provisioned through it just today. It’s been doing its job for five years.

The problem

The operator served us well at loveholidays. But our infrastructure has evolved. We’re running more clusters now, and their average lifespan is shorter. Operators are moving parts. Moving parts in short-lived clusters means more deployment complexity, more potential for state drift, more things to debug at 2am.

GKE now supports native methods that could replace our operator entirely. The problem? Migrating 1,484 service accounts - all attached to live, running applications - is a project that dwarfs the benefit of removing one small operator.

So we lived with it.

CRC16 as the unlock

Our operator generates deterministic resource names based on the ServiceAccount. Names like wi-marketing-tools-121f@random-gcp-project-name.iam.gserviceaccount.com - where 121f is a CRC16 checksum. To migrate away from the operator without touching existing resources, our Helm charts need to generate identical names.

Here’s what a CRC16 lookup table looks like in Helm:

{{- define "crc16.table" -}}
{{- dict
  0 0 1 49345 2 49537 3 320 4 49921 5 960 6 640 7 49729 8 50689 9 1728
  10 1920 11 51009 12 1280 13 50625 14 50305 15 1088 16 52225 17 3264 18 3456 19 52545
  20 3840 21 53185 22 52865 23 3648 24 2560 25 51905 26 52097 27 2880 28 51457 29 2496
  30 2176 31 51265 32 55297 33 6336 34 6528 35 55617 36 6912 37 56257 38 55937 39 6720
  40 7680 41 57025 42 57217 43 8000 44 56577 45 7616 46 7296 47 56385 48 5120 49 54465
  50 54657 51 5440 52 55041 53 6080 54 5760 55 54849 56 53761 57 4800 58 4992 59 54081
  60 4352 61 53697 62 53377 63 4160 64 61441 65 12480 66 12672 67 61761 68 13056 69 62401
  70 62081 71 12864 72 13824 73 63169 74 63361 75 14144 76 62721 77 13760 78 13440 79 62529
  80 15360 81 64705 82 64897 83 15680 84 65281 85 16320 86 16000 87 65089 88 64001 89 15040
  90 15232 91 64321 92 14592 93 63937 94 63617 95 14400 96 10240 97 59585 98 59777 99 10560
  100 60161 101 11200 102 10880 103 59969 104 60929 105 11968 106 12160 107 61249 108 11520 109 60865
  110 60545 111 11328 112 58369 113 9408 114 9600 115 58689 116 9984 117 59329 118 59009 119 9792
  120 8704 121 58049 122 58241 123 9024 124 57601 125 8640 126 8320 127 57409 128 40961 129 24768
  130 24960 131 41281 132 25344 133 41921 134 41601 135 25152 136 26112 137 42689 138 42881 139 26432
  140 42241 141 26048 142 25728 143 42049 144 27648 145 44225 146 44417 147 27968 148 44801 149 28608
  150 28288 151 44609 152 43521 153 27328 154 27520 155 43841 156 26880 157 43457 158 43137 159 26688
  160 30720 161 47297 162 47489 163 31040 164 47873 165 31680 166 31360 167 47681 168 48641 169 32448
  170 32640 171 48961 172 32000 173 48577 174 48257 175 31808 176 46081 177 29888 178 30080 179 46401
  180 30464 181 47041 182 46721 183 30272 184 29184 185 45761 186 45953 187 29504 188 45313 189 29120
  190 28800 191 45121 192 20480 193 37057 194 37249 195 20800 196 37633 197 21440 198 21120 199 37441
  200 38401 201 22208 202 22400 203 38721 204 21760 205 38337 206 38017 207 21568 208 39937 209 23744
  210 23936 211 40257 212 24320 213 40897 214 40577 215 24128 216 23040 217 39617 218 39809 219 23360
  220 39169 221 22976 222 22656 223 38977 224 34817 225 18624 226 18816 227 35137 228 19200 229 35777
  230 35457 231 19008 232 19968 233 36545 234 36737 235 20288 236 36097 237 19904 238 19584 239 35905
  240 17408 241 33985 242 34177 243 17728 244 34561 245 18368 246 18048 247 34369 248 33281 249 17088
  250 17280 251 33601 252 16640 253 33217 254 32897 255 16448
-}}
{{- end -}}

Would I have written this by hand? No. Would I have trusted myself to transcribe a 256-entry lookup table without errors? Also no.

With CRC16 in Helm, we can now:

  • Eliminate the operator entirely from new clusters
  • Avoid touching the 1,484 existing service accounts
  • Move identity-binding logic into the deployment pipeline, eliminating runtime reconciliation
  • Handle certain lifecycle edge cases (like ServiceAccount renames) more cleanly than the operator did

The whole implementation is maybe 50 lines of template logic. It would have taken me a week to write, test, and convince myself it handled edge cases correctly. That week was never worth spending.

The interesting shift here isn’t just that AI makes coding faster. It opens up possibilities that wouldn’t have stood a chance of scrutiny before. Now we can trade runtime complexity for code complexity - and that’s an easy bargain to make when you operate thousands of pods.