search

project-akri / akri-docs

Documentation for Akri
https://docs.akri.sh/
Apache License 2.0
8 stars 21 forks source link

proposal for onvif secret data schema #78

Closed johnsonshih closed 1 year ago

johnsonshih commented 1 year ago

Propose a schema of secret information in discoveryProperties passed to Onvif DiscoveryHandler

related to https://github.com/project-akri/akri/issues/250

diconico07 commented 1 year ago

I'd add a way to add some default value to this, the rationale is while a default/unique password kind of defeat the purpose of authentication, it can make sense for device onboarding where they all come with a default factory set password.

I'd also add a device property indicating from where the authentication information comes from (the device property key ? and if it is default credentials), it would allow a workload to know where to find the right credentials.

johnsonshih commented 1 year ago

I'd add a way to add some default value to this, the rationale is while a default/unique password kind of defeat the purpose of authentication, it can make sense for device onboarding where they all come with a default factory set password.

I'd also add a device property indicating from where the authentication information comes from (the device property key ? and if it is default credentials), it would allow a workload to know where to find the right credentials.

Add default credential support. For the exposing hints of credential source, I'm not sure if that is useful, as the broker has the capability to mount Kubernetes Secret directly, brokers can easily get credential by device uuid. I'll defer adding that hint in a separate change after fully investigating the usage of hint.

diconico07 commented 1 year ago

I'd add a way to add some default value to this, the rationale is while a default/unique password kind of defeat the purpose of authentication, it can make sense for device onboarding where they all come with a default factory set password. I'd also add a device property indicating from where the authentication information comes from (the device property key ? and if it is default credentials), it would allow a workload to know where to find the right credentials.

Add default credential support. For the exposing hints of credential source, I'm not sure if that is useful, as the broker has the capability to mount Kubernetes Secret directly, brokers can easily get credential by device uuid. I'll defer adding that hint in a separate change after fully investigating the usage of hint.

The main idea is, with your proposal a broker have to implement the exact same precedence between all sources, adding that property allows a broker to directly use the right source and it may ease debugging as well, as the credential source is shown. I agree that it's mostly a convenience property.

I won't block the proposal for this, it can be added later if we want to.