add the ability to specify sensitive data in the schema

[henderiw]

add sensitive data capabilities to hide this information in the configserver.

[alexandernorth]

I think this should probably search the target/config resource namespace, or use the SecretReference with a key selector so that the namespace can also be defined

[alexandernorth]

Should this be auto-filled by the config paths too? I would assume so, and extra ones can be defined here

[henderiw]

manage the sensitive paths through a dedicated CR: list of:

• path: xpath
  secretReference or None

Role of the ConfigServer:

• create a CR with the paths and resolve secrets or no value if not secret was set -> goal is to hint on asking the values (this should be a fairly high priority to always win)
• we might need to indicate this is a secret reference in the sdc proto

Role of the DataServer:

• replaces the paths through the config override
• masks these paths in running config or deviations

Other?

[alexandernorth]

manage the sensitive paths through a dedicated CR: list of:

• path: xpath
  secretReference or None

Role of the ConfigServer:

• create a CR with the paths and resolve secrets or no value if not secret was set -> goal is to hint on asking the values (this should be a fairly high priority to always win)
• we might need to indicate this is a secret reference in the sdc proto

Role of the DataServer:

• replaces the paths through the config override
• masks these paths in running config or deviations

Other?

Looks like what we discussed in the call - only question is about the config-server creating a CR: Am I understanding correctly that we will have a new SecretConfig resource, which is reconciled by config-server and will create a config intent through replacing SecretReferences with the value, or indicating a protected path?

[henderiw]

#192 (comment)

I am not sure we do a dedicated CR or extend the config CR with the paths. it allows to interleave this in a given config.

If the data server does the merging/ masking I feel it does not matter and hence we have more flexibility to the user as they can have different teams also for different parts of the config.

[henderiw]

So I feel it is best to handle the sensitive config in a seperate CRD, but there can be multiple to allow different teams to author different pieces of the config. This also Is easier for deviation handling, etc etc..

Do we store this in the same way in the apiserver, meaning not in etcd ?

Can we also assume these paths are always YANG leafs ?