(Define and) use Akri-specific Secret types

[sftim]

Is your feature request related to a way you would like Akri extended? Please describe.
Examples such as https://docs.akri.sh/demos/onvif-authentication-access suggesting defining Secrets with type Opaque. However, Kubernetes actually allows defining types of Secret that are more fine grained; for example, devices.akri.sh/onvif-credentials for ONVIF, or devices.akri.sh/tls-client for OPCUA broker credentials.

Using a type that isn't Opaque allows for admission-time validation (for example, you can validate that a Secret used with ONVIF has device_credential_list and credential_list keys, and that the values for these are both valid JSON documents). You can even get a Warning: to remind you not to use an Opaque secret with an Akri Configuration object; because it's a Warning, you get reminded but your existing manifests and charts carry on working.

Describe the solution you'd like

• Define a set of Secret types that Akri implementations should use.
• Update the documentation to recommend these.

Describe alternatives you've considered

• “Do nothing”, I guess.

Additional context
See Kubernetes' documentation on types of Secret.

[sftim]

Actually implementing the warnings, eg with a sample ValidatingAdmissionPolicy, would be a follow-up task once the Secret types are defined and documented.

[yujinkim-msft]

@sftim thank you for submitting this feature request, this seems like it would be a great addition!

@johnsonshih can you please take a look at this feature request? this is generally use-case/protocol specific. this might make more sense when we split the configuration - defining which secret types it can consume in discovery config and validate with admission webhook that the secret has correct structure for a given protocol/config.

[sftim]

admission webhook

I would use ValidatingAdmissionPolicy where available, but admission webhooks work too.