Versions Compared

Old Version 21

changes.mady.by.user Huifeng Le

Saved on

compared with

New Version 22

changes.mady.by.user Huifeng Le

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Restful API definition and Back-End flow

ResourceDescriptionURLFieldsBack-End flow
OverlayDefine a group of edge location clusters (devices) and hubs, a overlay is usually owned by one customer and full mesh connections are setup automacally between hub-hub and device-device (with public IPs)/scc/v1/overlays
  • name
  • description
  • caid

Registration:

  • SCC requests a CA from cert-manager, the CA is used as root CA for this overlay
  • SCC save the caid in DB
ProposalDefine proposals which can be used for IPsec tunnel in this overlay/scc/v1/overlays/{overlay-name}/proposals
  • name
  • description
  • encryption
  • hash
  • dhgroup

Registration:

  • SCC saves the proposals information in DB
HubDefine a traffic Hub in an overlay/scc/v1/overlays/{overlay-name)/hubs
  • name
  • description
  • publicIps
  • certificateId
  • kubeConfig

Registration:

  • SCC checks hub's k8s API server access with kubeConfig for each ip in publicIps
  • For each registered hub in this overlay
    • SCC requests cert-manager to generate a public/private key pair based on overlay CA
    • SCC generates the IPsec CR for new hub and registered hub then call rsync to deploy CR to setup route based host-host IPsec tunnel (with BGP/OSPF enabled):
      • All proposals in this Overlay will be used as candidate proposals for IPsec configuration
      • Use the public/privite key pair generated in previous step as IPsec cert
  • SCC saves hub information in DB
IPRangeDefine the overlay IPrange which will be used as OIP of devices/scc/v1/overlays/{overlay-name}/ipranges
  • name
  • description
  • subnet
  • minIp
  • maxIp

Registration:

  • SCC save ip range information in DB
DeviceDefine a edge location device information which may be a CNF, VNF or PNF/scc/v1/overlays/{overlay-name}/devices
  • name
  • description
  • publicIps
  • forceHubConnectivity
  • proxyHub
  • proxyHubPort
  • useHub4Internet
  • dedidatedSFC
  • certicatedId
  • kubeConfig

Registration:

  • If has publicIps and forceHubConnection==false:

    • SCC checks device's k8s API server access with kubeConfig for each ip in publicIps

    • For each registered device of this overlay:

      • SCC requests cert-manager to generate a public/private key pair based on overlay CA
      • SCC generates the IPsec CR for new device and registered device then call rsync to deploy CR to setup host-host IPsec tunnel:
        • All proposals in this Overlay will be used as candidate proposals for IPsec configuration
        • Use the public/privite key pair generated in previous step as IPsec cert
  • else
    • (Assumption) Kud configures device as Initiator to proxyHub
    • SCC find 1 available OIP from overlay's IPRange, configure then deploy (through rsync) IPsec CR for proxyHub as Responder with OIP as the only 1 candidate ip for Initiator
      • Expectation: the IPsec tunnel between proxyHub and device should setup up and the device will get the assigned OIP
    • SCC creates DNAT CR (dst: HIP, dst_port: proxyHubPort change to dst: OIP, dst_port: 6443) then deploy to proxyHub (SCC will auto geterate a proxyHubPort if not provided)
    • SCC checks device's k8s API server access with kubeConfig for proxyHub:proxyHubPort

    • For each registered device with public ip and forceHubConnection==false:

      • SCC requests cert-manager to generate a public/private key pair based on overlay CA
      • SCC generates the IPsec CR for new device and registered device (with public IP) then call rsync to deploy CR to setup host-host IPsec tunnel:
        • All proposals in this Overlay will be used as candidate proposals for IPsec configuration
        • Use the public/privite key pair generated in previous step as IPsec cert
  • SCC saves device information in DB
Hub-device connectionDefine a connection between hub and device/scc/v1/overlays/{overlay-name}/hubs/{hub-name}/devices/{device-name}
  • N/A

Create:

  • SCC find 1 available OIP from overlay's IPRange, configure then deploy (through rsync) IPsec CR for hub as Responder with OIP as the only 1 candidate ip for Initiator
  • SCC configure the deploy IPsec CR as Initiator to Hub for device
    • Expectation: the IPsec tunnel between hub and device should setup up and the device will get the assigned OIP

Todo: Confirm "ip route" rule for OIP in this hub and all other hub are setup automatically or need new CR to execute linux shell in host

Register Hub:

  • Trigger: Admin add/update hub information in Web UI or Remote Client Call with below informations:
    • Name, Description
    • Public IP address list
    • Managed IP ( ? )
    • Shared flag (whether the hub can be shared cross overlays)
    • Overlay name
    • CertificateId
    • Kubeconfig
  • Steps:
    • Save in DB
    • Setup control plane host-host tunnel with Central Cloud (e.g. Add a new IPSec policy in Central Cloud CNF with: left: CIP, right: HIP, CertificateId)

...