Node management

Rules

Users of for node groups can define a set of rules that are specific to a specified operating system. The Rules section of the NodeGroup resource includes the following parameters that define a rule:

• An action, which can be one of the following:
  • Deny
  • ReadWrite
  • Read
• An operatingSystem - which OS to apply this rule to.
• A match - an OS-specific path, for example interface for SR Linux, or configure port for SR OS.

Rules that match the operating system of the target are deployed to that target.

The default for action is set to ReadWrite, and to simplify the majority of deployments the operatingSystem is set to srl.

Superuser

EDA supports a superuser attribute; if enabled for a node user group, users that belong to the node group can perform all functions on the system, including sudo and root access, if available.

TACACS+

System administrators commonly use TACACS+ to authenticate users, and then use the local device to enforce a locally-defined rule set, or role. In EDA, enforcement uses the privilege level in TACACS+. If TACACS+ is used for authentication and if a privilege level is returned, a user is granted the set of permissions from all groups that match that privilege level and lower (following TACACS+ implementation of higher privilege levels inheriting permissions of lower levels).

Services

Default sudo group

The default sudo node group is provided during the bootstrap process or playground deployment. This group enables critical services and provides read/write access to all paths. The NodeGroup resource is referenced by the admin NodeUser resource that is provided with playground KPT package.

The following example shows a sudo NodeGroup resource:

apiVersion: core.eda.nokia.com/v1
kind: NodeGroup
metadata:
  name: sudo
  namespace: eda
spec:
  services:
  - GNMI
  - CLI
  - NETCONF
  superuser: true

Node selection

In NodeSecurityProfile resource, you can select nodes using the following methods:

The nodes field takes precedence over the nodeSelector setting. If multiple profiles match a node's labels, the profile whose name is first in alphabetic order is applied.

TLS configuration

The tls context indicates whether the connection to the node is secure (with TLS) or insecure (without TLS). The absence of the tls field implies an insecure connection, while its presence signals a secure connection.

EDA-managed certificates

When EDA is responsible for managing node certificates, the tls context must include the following entries:

• issuerRef: a reference to a CertManager Issuer, which is responsible for issuing the certificates.

• csrParams: the Certificate Signing Request (CSR) parameters define the parameters for certificate generation and rotation.

  • csrSuite: the key and digest set to be used for generating the CSR.
  • commonName: the common name (CN) to include in the certificate. This value is auto-generated.
  • country: the legally registered country of the organization.
  • state: the state or province where the organization is located.
  • city: the city in which the organization is based.
  • org: the name of the organization requesting the CSR.
  • orgUnit: the department or division within the organization requesting the certificate.
  • certificateValidity: the duration for which the certificate remains valid post-issuance.
  • SAN (Subject Alternative Names):
    • dns: List of DNS names used to access the node.
    • emails: Email addresses associated with the certificate.
    • ips: IP addresses that the certificate should validate.
    • uris: Specific URIs that the certificate needs to authenticate.

The following is an example of a nodeSecurityProfile CR where EDA manages certificates:

apiVersion: v1
items:
  - apiVersion: core.eda.nokia.com/v1
    kind: NodeSecurityProfile
    metadata:
      annotations:
        config.k8s.io/owning-inventory: 8c2644abc6befe73d5ad0cfc386ec155f31bc07d-1729769165484669347
        kubectl.kubernetes.io/last-applied-configuration: >
          {"apiVersion":"core.eda.nokia.com/v1","kind":"NodeSecurityProfile","metadata":{"annotations":{"config.k8s.io/owning-inventory":"8c2644abc6befe73d5ad0cfc386ec155f31bc07d-1729769165484669347"},"name":"insecure","namespace":"default"},"spec":{"nodeSelector":["eda.nokia.com/security-profile=insecure"]}}
      name: insecure
      namespace: eda
    spec:
      nodeSelector:
        - eda.nokia.com/security-profile=insecure
  - apiVersion: core.eda.nokia.com/v1
    kind: NodeSecurityProfile
    metadata:
      annotations:
        config.k8s.io/owning-inventory: 8c2644abc6befe73d5ad0cfc386ec155f31bc07d-1729769165484669347
        kubectl.kubernetes.io/last-applied-configuration: >
          {"apiVersion":"core.eda.nokia.com/v1","kind":"NodeSecurityProfile","metadata":{"annotations":{"config.k8s.io/owning-inventory":"8c2644abc6befe73d5ad0cfc386ec155f31bc07d-1729769165484669347"},"name":"managed-tls","namespace":"default"},"spec":{"nodeSelector":["eda.nokia.com/security-profile=managed"],"tls":{"csrParams":{"certificateValidity":"2160h","city":"Sunnyvale","country":"US","csrSuite":"CSRSUITE_X509_KEY_TYPE_RSA_2048_SIGNATURE_ALGORITHM_SHA_2_256","org":"NI","orgUnit":"EDA","state":"California"},"issuerRef":"eda-node-issuer"}}}
      name: managed-tls
      namespace: eda
    spec:
      nodeSelector:
        - eda.nokia.com/security-profile=managed
      tls:
        csrParams:
          certificateValidity: 2160h
          city: Sunnyvale
          country: US
          csrSuite: CSRSUITE_X509_KEY_TYPE_RSA_2048_SIGNATURE_ALGORITHM_SHA_2_256
          org: NI
          orgUnit: EDA
          state: California
        issuerRef: eda-node-issuer
  - apiVersion: core.eda.nokia.com/v1
    kind: NodeSecurityProfile
    metadata:
      annotations:
        config.k8s.io/owning-inventory: 8c2644abc6befe73d5ad0cfc386ec155f31bc07d-1729769165484669347
        kubectl.kubernetes.io/last-applied-configuration: >
          {"apiVersion":"core.eda.nokia.com/v1","kind":"NodeSecurityProfile","metadata":{"annotations":{"config.k8s.io/owning-inventory":"8c2644abc6befe73d5ad0cfc386ec155f31bc07d-1729769165484669347"},"name":"unmanaged-tls","namespace":"default"},"spec":{"nodeSelector":["eda.nokia.com/security-profile=unmanaged"],"tls":{"trustBundle":"eda-node-trust-bundle"}}}
      name: unmanaged-tls
      namespace: eda
    spec:
      nodeSelector:
        - eda.nokia.com/security-profile=unmanaged
      tls:
        trustBundle: eda-node-trust-bundle
kind: List
metadata:
  resourceVersion: ""

External certificate management

apiVersion: core.eda.nokia.com/v1
kind: NodeSecurityProfile
metadata:
  name: example-node-security-profile
spec:
  nodeSelector:
    - "eda.nokia.com/role=leaf"
  tls:
    trustBundle: "node-trust-bundle"

Management interface IP address assignment

The Init resource allows you to configure the management interface IP assignment method using DHCP or by defining static IP addresses. For details, see Enabling DHCP clients and Setting static management IP addresses.

Saving node configuration on commit

To specify whether the node configuration is saved after each commit or not, in the Init CR include the entry commitSave: true. The Init script must reflect the commitSave value in the generated initial configuration.

DHCP server

In deployments that use EDA to handle ZTP in its entirety, a DHCP server is required to provide IP addresses to devices.

When a device issues a DHCP discovery message, the client-id option (61) attribute includes their chassis serial number. This serial number is used to associate real devices with node objects in EDA. Additionally, an IP address is assigned to device via a Target object.

The DHCP server must support the following capabilities:

• Static lease assignment using the client-id (option 61) as the binding between an IP address and a device
• Ability to receive DHCP packets from a DHCP relay (the DHCP relay between the devices and the DHCP server)
• When providing an IP address to the device, the DHCP server must be able to populate option 66 or 67 in the DHCP offer. This option provides HTTPs. The URL points to the ZTP provisioning script or boot file hosted on the artifact server.
• Ability to populate other options as required by the operator, for example:
  • Router option 3
  • Time Server option 4
  • Name Server option 5
  • Domain Server option 6
  • Log server option 7
• Support both IPv4 and IPv6 IP addressing