Sensitive Config

[henderiw]

Track the activities regarding sensitive data:

[henderiw]

Maybe worth a discussion, the current proposal is this

apiVersion: config.sdcio.dev/v1alpha1
kind: SensitiveConfig
metadata:
name: test
labels:
config.sdcio.dev/targetName: core01
config.sdcio.dev/targetNamespace: default
spec:
priority: 10
revertive: false
config:

• path: network-instance[mgmt]/protocols/bgp/neighbor[1.1.1.1]/password
  secretRef:
  key: bgp
  name: secretName

The key questions here are:

1. can orchestration systems deal with this or not?
2. now we have a BGP config snippet and a sensitive data snippet -> they somehow belong together, but are authored in 2 seperate CR(s)

Alternatives are:

Alternative 1:

• add the sensitive config in the config CR in a sensitive config section or add a sensitive config flag

this would look like this

apiVersion: config.sdcio.dev/v1alpha1
kind: SensitiveConfig
metadata:
name: test
labels:
config.sdcio.dev/targetName: core01
config.sdcio.dev/targetNamespace: default
spec:
priority: 10
revertive: false
config:

• path: /
  value:
  network-instance:
  name: Mgmt
  protocols:
  bgp:
  xxxxx
• path: network-instance[mgmt]/protocols/bgp/neighbor[1.1.1.1]/password
  secretRef:
  key: bgp
  name: secretName

this potentially addresses #2, but not 1

Alternative 2

we inline the secret ref with a marker

apiVersion: config.sdcio.dev/v1alpha1
kind: SensitiveConfig
metadata:
name: test
labels:
config.sdcio.dev/targetName: core01
config.sdcio.dev/targetNamespace: default
spec:
priority: 10
revertive: false
config:

• path: /
  value:
  network-instance:
  name: Mgmt
  protocols:
  bgp:
  xxxxx
  password: $$:

For alternative 2 we need to parse the data to find it, so this is more cumbersome, but the data stays coherent and orchestration systems might deal with this better

[markafarrell]

I quite like alternative 2.

Its similar to how flux does ResourceSets

https://fluxoperator.dev/docs/crd/resourceset/

[henderiw]

I tend to agree this is more natural from an orchestration system that would sit above as it becomes an integrated config artefact.

[steiler]

I have had a quick discussion with AI and it also thinks that alternative 2 is the best, but with a slight modification.
Make data-server resolve the secrets just before applying the config.

Proposal: Native Secret Resolution within data-server

To support sensitive data (passwords, auth-keys) within arbitrary YANG configurations (typically handled via runtime.RawExtension), the most robust approach is to have the data-server act as the resolution point rather than the upstream Kubernetes reconciler.

In this model, the Intent contains a Reference URI (e.g., sdc://secret/<name>/<key>), and the data-server inflates this into plaintext only at the SBI (Southbound Interface) layer during the transition from intended to applied state.

Pros

• Security (Minimal Exposure): Plaintext secrets never travel between the reconciler and the data-server. They are not stored in the data-server cache/DB and are never exposed via Northbound "Get" APIs, which would only return the Reference URI.
• Architectural Cleanliness: Upstream reconcilers are relieved from "search and replace" duties inside complex, arbitrary RawExtension blobs. They simply pass the YANG-compliant reference through.
• Atomic State Integrity: By having the data-server watch the Secret, it can trigger an automated push to the device the moment a credential rotates, ensuring the intended state remains synchronized with the actual device configuration.
• Performance: Centralizing the Secret Informer/Watch within the data-server reduces cluster overhead by eliminating redundant watches across multiple controller instances.

Cons

• Internal Complexity: Requires the data-server to implement a SecretResolver interface and supporting plugins (e.g., for K8s Secrets, Vault, etc.).
• Schema Validation: The data-server must be configured to allow URI-formatted strings in leaves that might have specific YANG constraints, though most credential fields are base types (string/binary).

Recommendation

Adopt a standardized URI format for secret references within the YANG tree. This enables Late-Binding Resolution: fetching and injecting the secret value only at the moment of device application. This keeps the "Source of Truth" secure and follows the principle of least privilege.

[henderiw]

if we agree that Alternative 2 is the way forward. Now we need to see how we best implement this.

There are several things that are needed:

1. what we dont do today and what we could add is we validate the schema syntax (not leaf ref) on entering the api
2. we need to know if a secret changed which targets need to be reconciled -> here we don't need the data but we need to use it as a trigger to do the work.
3. we need a mechanism to resolve the schema ref to the value.