Deploying Service Chain (cSRX) with JCNR
SUMMARY Read this section to learn how to customize and deploy a security services instance (cSRX) with the Cloud-Native Router.
You can integrate the Juniper Cloud-Native Router (JCNR) with Juniper's containerized SRX (cSRX) platform to provide security services such as IPsec. Using host-based service chaining, the cloud-native router is chained with a security service instance (cSRX) in the same Kubernetes cluster. The cSRX instance runs as a pod service in L3 mode. The cSRX instance is customized and deployed via a Helm chart.
You have the option of deploying Juniper cSRX when you're installing JCNR or after you've installed JCNR. See JCNR Software Download Packages for a description of the available packages.
Install cSRX on an Existing JCNR Installation
Follow this procedure to install a cSRX instance on an existing JCNR installation. Ensure all JCNR components are up and running before you start this procedure.
Install cSRX During JCNR Installation
Apply the cSRX License and Configure cSRX
Follow this procedure to apply your cSRX license and configure Juniper cSRX.
The following steps assume you're in the Juniper_Cloud_Native_Router_CSRX_<release> directory if installing cSRX and JCNR together, or in the junos_csrx_<release> directory if installing cSRX on an existing JCNR installation.
Customize cSRX Helm Chart
The cSRX service chaining instance is deployed via a Helm chart, either a standalone Helm chart or a combined Helm chart with JCNR. The deployment consists of two essential components:
-
csrx-init: This is an init container that prepares the configuration for the main cSRX application. It extracts the necessary information from the
values.yaml
file, processes it, and generates the configuration data for cSRX. This ensures that the main cSRX application starts with a valid, up-to-date configuration. -
csrx: The csrx is the main application container and the core component of the cSRX deployment. It relies on the configuration provided by the
csrx-init
container to function correctly.
You can customize the cSRX deployment by specifying a range of configuration
parameters in the values.yaml
file. Key configuration options
include:
-
interfaceType: This is the type of interface on the cSRX to connect to JCNR. Must be set to
vhost
only. -
interfaceConfigs: This is an array defining the interface IP address, gateway address and optionally routes. The interface IP must match the
localAddress
element in theipSecTunnelConfigs
array. The routes should contain prefixes to steer decrypted traffic to JCNR and reachability route for IPSec gateway. -
ipSecTunnelConfigs: This is an array defining the IPsec configuration details such as ike-phase1, proposal, policy and gateway configuration. Traffic selector should contain traffic that is expected to be encrypted.
-
jcnr_config: This is an array defining the routes to be configured in JCNR to steer traffic from JCNR to cSRX and to steer IPsec traffic from the remote IPsec gateway to the cSRX to apply the security service chain.
Here is the default values.yaml for standalone cSRX deployment:
# Default values for cSRX. # This is a YAML-formatted file. # Declare variables to be passed into your templates. common: registry: enterprise-hub.juniper.net/ repository: jcnr-container-prod/ csrxInit: image: csrx-init tag: f4tgt33 imagePullPolicy: IfNotPresent resources: #limits: # memory: 1Gi # cpu: 1 #requests: # memory: 1Gi # cpu: 1 csrx: image: csrx tag: 24.2R1.14 imagePullPolicy: IfNotPresent resources: limits: hugepages-1Gi: 4Gi memory: 4Gi requests: hugepages-1Gi: 4Gi memory: 4Gi # uncomment below if you are using a private registry that needs authentication # registryCredentials - Base64 representation of your Docker registry credentials # secretName - Name of the Secret object that will be created #imagePullSecret: #registryCredentials: <base64-encoded-credential> #secretName: regcred # nodeAffinity: Can be used to inject nodeAffinity for cSRX # you may label the nodes where we wish to deploy cSRX and inject affinity accordingly #nodeAffinity: #- key: node-role.kubernetes.io/worker # operator: Exists #- key: node-role.kubernetes.io/master # operator: DoesNotExist #- key: kubernetes.io/hostname # operator: In # values: # - example-host-1 replicas: 1 interfaceType: "vhost" interfaceConfigs: #- name: eth1 # ip: 181.1.1.1/30 # should match ipSecTunnelConfigs localAddress if configured # gateway: 181.1.1.2 # gateway configuration # ip6: 181:1:1::1/64 # optional # ip6Gateway: 181:1:1::2 # optional # routes: # this field is optional # - "191.1.1.0/24" # - "200.1.1.0/24" #- name: eth2 # ip: 1.21.1.1/30 # should match ipSecTunnelConfigs localAddress if configured # gateway: 1.21.1.2 # gateway configuration # ip6: 181:2:1::1/64 # optional # ip6Gateway: 181:2:1::2 # optional # routes: # this field is optional # - "111.1.1.0/24" # - "192.1.1.0/24" ipSecTunnelConfigs: # untrust #- interface: eth1 ## section ike-phase1, proposal, policy, gateway # gateway: 171.1.1.1 # localAddress: 181.1.1.1 # authenticationAlgorithm: sha-256 # encryptionAlgorithm: aes-256-cbc # preSharedKey: "$9$zt3l3AuIRhev8FnNVsYoaApu0RcSyev8XO1NVYoDj.P5F9AyrKv8X" # trafficSelector: # - name: ts1 # localIP: 111.1.1.0/24 ## IP cannot be 0.0.0.0/0 # remoteIP: 222.1.1.0/24 ## IP cannot be 0.0.0.0/0 jcnr_config: #- name: eth1 # routes: # - "121.1.1.0/24" #csrx_flavor: specify the csrx deployment model. Corresponding values for csrx control and data cpus #must be provided based on the flavor mentioned below. Following are possible options: # CSRX-2CPU-4G # CSRX-4CPU-8G # CSRX-6CPU-12G # CSRX-8CPU-16G # CSRX-16CPU-32G # CSRX-20CPU-48G csrx_flavor: CSRX-2CPU-4G csrx_ctrl_cpu: "0x01" csrx_data_cpu: "0x02"