You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Actually implementing the warnings, eg with a sample ValidatingAdmissionPolicy, would be a follow-up task once the Secret types are defined and documented.
@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.
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, ordevices.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
andcredential_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
Describe alternatives you've considered
Additional context
See Kubernetes' documentation on types of Secret.
The text was updated successfully, but these errors were encountered: