secrets: relax key name restrictions

[dagframstad]

Beskrivelse / Essensen

Lette på restriksjoner for nøkler tilhørende Secrets slik at vi også tillater - og .

Investeringsvilje

<1 uke

Ikke-mål

Mulig løsning i grove trekk

Oppdatere valideringskode i console-frontend og api:

• console-frontend/src/routes/team/[team]/(teamPages)/[env]/secret/[secret]/AddKeyValue.svelte

  Lines 31 to 53 in f3f86d7

  	const validKey = (key: string | undefined) => {
  	if (!key) {
  	return '';
  	}
  	const existingKeys = initial.map((kv) => kv.name);
  	if (existingKeys.includes(key) || addedKey(key, initial, changes)) {
  	return 'Key already exists';
  	}
  	if (key.length > 253) {
  	return 'Must be less than 253 characters';
  	}
  	if (/^[_a-zA-Z0-9]+$/.test(key) === false) {
  	return 'Can only contain letters, numbers, or _';
  	}
  	if (/^[a-zA-Z_]+/.test(key) === false) {
  	return 'Must start with a letter or _';
  	}
  	return '';
  	};

• https://github.com/nais/api/blob/65dd40901795fe86ac55bc4568e93394264c1020/internal/k8s/secrets.go#L393-L416

For api kan man evt. bare bruke validation.IsEnvVarName() direkte.

---

Original comment below:

We have code that does stuff with files at startup depending on the file extension.
It would be nice to be able to use a dot (.) in a secrets key. This would be very handy when mounting the secret as a file (using fromFiles in the nais manifest).
I understand that it's impossible if the secret is used as an environment entry (envFrom), but you could fail application startup if a secret with a dot in the key is used as an environment variable (or be nice and replace the dot with an underscore at startup).

And while I'm at it, why not allow dash, -, as well?

[tronghn]

Please correct me if I've misunderstood, but the short version is that you would like to be able to use the . and - characters when defining Secret keys? 🙂

The original intention was to be compliant with the POSIX shell standards for environment variable names, though this evidently complicates matters when a Secret is mounted as files.

We're likely not going to introduce implicit behaviours that modify or replace keys as that will only lead to further confusion, but we can consider relaxing the current restrictions similarily to kubernetes/kubernetes#48986

[dagframstad]

Yes, thats exactly what I want.