Articles in this section

See more

How To Whitelist an IP Address

Jake Diga
  • Updated
Follow

Background

For security purposes, access to a Domino deployment is restricted by security groups to accept incoming connections from pre-selected CIDRs. Usually it is required to contact Domino support to make modifications to the list of accepted CIDRs; however, this documentation provides sufficient information for Domino administrators to make simple modifications to the list.

Caveats

  • Making such changes to the security groups can complicate future runs of the Domino deployer so it is imperative that Domino support be informed of any changes made to IP whitelisting through a support ticket.
  • The following instructions only cover basic additions and removals from the list of authorised CIDRs. More complex scenarios than just allowing/disallowing a particular CIDR will still require contacting Domino support.
  • AWS has a default limit of 60 rules in a security group. The Domino executor security group requires 3 rules per CIDR thus limiting the number of unique CIDRs to 20. If more are needed, request an AWS rule limit change to 100 which will allow 33 unique CIDRs. For more than that, please consult with Domino support.

Preparation

You will need to know:

  • Whether your deployment is full Kubernetes (Domino 4.x+) or partial Kubernetes (generally speaking this is Domino 3.x.)
  • The stage name for your deployment. For example, if your company name is Acme Inc. and you’re working on your dev deployment then your stage name may be acmedev (or something similar) In the following steps replace STAGE with the appropriate stage name.

When editing the security groups in the AWS console, you will only update the Incoming rules of the security group. The required fields for Incoming rules are:

  • Type - HTTP, HTTPS, SSH, Custom port, etc.
  • Protocol - TCP, UDP, ICMP, etc.
  • Port range - the range of ports to allow connections to.
  • Source - the CIDR of the allowed incoming connections.

An example of this is shown below (CIDRs obscured for security reasons.)

Background

For security purposes, access to a Domino deployment is restricted by security groups to accept incoming connections from pre-selected CIDRs. Usually it is required to contact Domino support to make modifications to the list of accepted CIDRs; however, this documentation provides sufficient information for Domino administrators to make simple modifications to the list.

Caveats

  • Making such changes to the security groups can complicate future runs of the Domino deployer so it is imperative that Domino support be informed of any changes made to IP whitelisting through a support ticket.
  • The following instructions only cover basic additions and removals from the list of authorised CIDRs. More complex scenarios than just allowing/disallowing a particular CIDR will still require contacting Domino support.
  • AWS has a default limit of 60 rules in a security group. The Domino executor security group requires 3 rules per CIDR thus limiting the number of unique CIDRs to 20. If more are needed, request an AWS rule limit change to 100 which will allow 33 unique CIDRs. For more than that, please consult with Domino support.

Preparation

You will need to know:

  • Whether your deployment is full Kubernetes (Domino 4.x+) or partial Kubernetes (generally speaking this is Domino 3.x.)
  • The stage name for your deployment. For example, if your company name is Acme Inc. and you’re working on your dev deployment then your stage name may be acmedev (or something similar) In the following steps replace STAGE with the appropriate stage name.

When editing the security groups in the AWS console, you will only update the Incoming rules of the security group. The required fields for Incoming rules are:

  • Type - HTTP, HTTPS, SSH, Custom port, etc.
  • Protocol - TCP, UDP, ICMP, etc.
  • Port range - the range of ports to allow connections to.
  • Source - the CIDR of the allowed incoming connections.

An example of this is shown below (CIDRs obscured for security reasons.)

ip_whitelist.png

Steps

Below are the steps for updating IP whitelisting for both Domino 3.x and 4.x & above. At any stage when running through these steps, if an error occurs then please record the error and the steps you have taken, then report the issue in a support ticket. You can use the Rollback section to rollback any changes made.

For Domino version 3.x and below

    1. In the AWS console update the following security groups for your VPC:
  • STAGE-general-admin
        1. Type: SSH, Protocol: TCP, Port Range: 22
        2. Type: All ICMP-IPv4 , Protocol: ICMP, Port range: All
      1. STAGE-domino_fe_ext_elb (this is labeled as STAGE-general-access in full Kubernetes deployments)
        1. Type: HTTP, Protocol: TCP, Port range: 80
        2. Type: HTTPS, Protocol: TCP, Port range: 443
  • STAGE-executor
      1. Type: Custom TCP, Protocol: TCP, Port range: 9000
      2. Type: Custom TCP, Protocol: TCP, Port: 49000-49999
      3. Type: SSH, Protocol: TCP, Port range: 22
    1. STAGE-domino_fe_int (skip if it doesn’t exist)
      1. Type: HTTP, Protocol: TCP, Port range: 80
      2. Type: HTTPS, Protocol: TCP, Port range: 443
      3. Type: Custom TCP, Protocol: TCP, Port range: 9000

  1.  
    1. Login to the salt master and edit /srv/pillar/custom/overrides.sls and look for sections access and admin_cidr and update them appropriately with the new CIDR(s).
    2. Verify the ELBs are present in the deployment either through the AWS console or by running the command

      kubectl get svc | grep traefik-ing

    3. Next, go to the directory /domino/k8s. There are two files here, traefik-ingress-external.yaml and traefik-ingress-internal.yaml corresponding to the two Kubernetes Elastic Load Balancers.
      Update both of these files to include the new CIDR(s) and then apply the changes with

      kubectl apply -f traefik-ingress-external.yaml
      kubectl apply -f traefik-ingress-internal.yaml

  2. IMPORTANT: Communicate the CIDRs added to your deployment to Domino support so that future runs of the deployer will not revert your changes.

For Domino versions 4.x and above

    1. In the AWS console update the following security groups for your VPC:
  • STAGE-general-admin
        1. Type: SSH, Protocol: TCP, Port Range: 22
        2. Type: All ICMP-IPv4 , Protocol: ICMP, Port range: All
  • STAGE-general-access
      1. Type: HTTP, Protocol: TCP, Port range: 80
      2. Type: HTTPS, Protocol: TCP, Port range: 443
    1. STAGE-domino_fe_int (skip if it doesn’t exist)
      1. Type: HTTP, Protocol: TCP, Port range: 80
      2. Type: HTTPS, Protocol: TCP, Port range: 443
      3. Type: Custom TCP, Protocol: TCP, Port range: 9000

  1. Login to a node that can run kubectl. The primary Kubernetes security group for general access is controlled by the nginx-ingress-controller. To add CIDR(s), leverage kubectl and run 

kubectl edit service nginx-ingress-controller -n domino-platform

Locate the section spec.loadBalancerSourceRanges to add the new CIDR(s).

  1. IMPORTANT: Communicate the CIDR(s) added to your deployment to Domino support so that future runs of the deployer will not revert your changes.

Rollback

In the case that you need to rollback the changes the steps are the reverse of those for applying the changes.

For Domino version 3.x and below

    1. In the AWS console remove the CIDR(s) from the following security groups for your VPC:
  • STAGE-general-admin
        1. Type: SSH, Protocol: TCP, Port Range: 22
        2. Type: All ICMP-IPv4 , Protocol: ICMP, Port range: All
      1. STAGE-domino_fe_ext_elb (this is labeled as STAGE-general-access in full Kubernetes deployments)
        1. Type: HTTP, Protocol: TCP, Port range: 80
        2. Type: HTTPS, Protocol: TCP, Port range: 443
  • STAGE-executor
      1. Type: Custom TCP, Protocol: TCP, Port range: 9000
      2. Type: Custom TCP, Protocol: TCP, Port: 49000-49999
      3. Type: SSH, Protocol: TCP, Port range: 22
    1. STAGE-domino_fe_int (skip if it doesn’t exist)
      1. Type: HTTP, Protocol: TCP, Port range: 80
      2. Type: HTTPS, Protocol: TCP, Port range: 443
      3. Type: Custom TCP, Protocol: TCP, Port range: 9000

  1.  
    1. Login to the salt master and edit /srv/pillar/custom/overrides.sls and look for sections access and admin_cidr and remove the CIDR(s) from each section where it appears.
    2. Verify the ELBs are present in the deployment either through the AWS console or by running the command

      kubectl get svc | grep traefik-ing

    3. Next, go to the directory /domino/k8s. There are two files here, traefik-ingress-external.yaml and traefik-ingress-internal.yaml corresponding to the two Kubernetes Elastic Load Balancers.
      Update both of these files to remove the CIDR(s) and then apply the changes with

      kubectl apply -f traefik-ingress-external.yaml
      kubectl apply -f traefik-ingress-internal.yaml

  2. IMPORTANT: Communicate the CIDRs removed from your deployment to Domino support so that future runs of the deployer will not revert your changes.

For Domino versions 4.x and above

    1. In the AWS console remove the CIDR(s) from the following security groups for your VPC:
  • STAGE-general-admin
        1. Type: SSH, Protocol: TCP, Port Range: 22
        2. Type: All ICMP-IPv4 , Protocol: ICMP, Port range: All
  • STAGE-general-access
      1. Type: HTTP, Protocol: TCP, Port range: 80
      2. Type: HTTPS, Protocol: TCP, Port range: 443
    1. STAGE-domino_fe_int (skip if it doesn’t exist)
      1. Type: HTTP, Protocol: TCP, Port range: 80
      2. Type: HTTPS, Protocol: TCP, Port range: 443
      3. Type: Custom TCP, Protocol: TCP, Port range: 9000

  1. Login to a node that can run kubectl. The primary Kubernetes security group for general access is controlled by the nginx-ingress-controller. To remove CIDR(s), leverage kubectl and run 

kubectl edit service nginx-ingress-controller -n domino-platform

Locate the section spec.loadBalancerSourceRanges to remove the CIDR(s).

  1. IMPORTANT: Communicate the CIDRs removed from your deployment to Domino support so that future runs of the deployer will not revert your changes.



Steps

Below are the steps for updating IP whitelisting for both Domino 3.x and 4.x & above. At any stage when running through these steps, if an error occurs then please record the error and the steps you have taken, then report the issue in a support ticket. You can use the Rollback section to rollback any changes made.

For Domino version 3.x and below

    1. In the AWS console update the following security groups for your VPC:
  • STAGE-general-admin
        1. Type: SSH, Protocol: TCP, Port Range: 22
        2. Type: All ICMP-IPv4 , Protocol: ICMP, Port range: All
      1. STAGE-domino_fe_ext_elb (this is labeled as STAGE-general-access in full Kubernetes deployments)
        1. Type: HTTP, Protocol: TCP, Port range: 80
        2. Type: HTTPS, Protocol: TCP, Port range: 443
  • STAGE-executor
      1. Type: Custom TCP, Protocol: TCP, Port range: 9000
      2. Type: Custom TCP, Protocol: TCP, Port: 49000-49999
      3. Type: SSH, Protocol: TCP, Port range: 22
    1. STAGE-domino_fe_int (skip if it doesn’t exist)
      1. Type: HTTP, Protocol: TCP, Port range: 80
      2. Type: HTTPS, Protocol: TCP, Port range: 443
      3. Type: Custom TCP, Protocol: TCP, Port range: 9000

  1.  
    1. Login to the salt master and edit /srv/pillar/custom/overrides.sls and look for sections access and admin_cidr and update them appropriately with the new CIDR(s).
    2. Verify the ELBs are present in the deployment either through the AWS console or by running the command

      kubectl get svc | grep traefik-ing

    3. Next, go to the directory /domino/k8s. There are two files here, traefik-ingress-external.yaml and traefik-ingress-internal.yaml corresponding to the two Kubernetes Elastic Load Balancers.
      Update both of these files to include the new CIDR(s) and then apply the changes with

      kubectl apply -f traefik-ingress-external.yaml
      kubectl apply -f traefik-ingress-internal.yaml

  2. IMPORTANT: Communicate the CIDRs added to your deployment to Domino support so that future runs of the deployer will not revert your changes.

For Domino versions 4.x and above

    1. In the AWS console update the following security groups for your VPC:
  • STAGE-general-admin
        1. Type: SSH, Protocol: TCP, Port Range: 22
        2. Type: All ICMP-IPv4 , Protocol: ICMP, Port range: All
  • STAGE-general-access
      1. Type: HTTP, Protocol: TCP, Port range: 80
      2. Type: HTTPS, Protocol: TCP, Port range: 443
    1. STAGE-domino_fe_int (skip if it doesn’t exist)
      1. Type: HTTP, Protocol: TCP, Port range: 80
      2. Type: HTTPS, Protocol: TCP, Port range: 443
      3. Type: Custom TCP, Protocol: TCP, Port range: 9000

  1. Login to a node that can run kubectl. The primary Kubernetes security group for general access is controlled by the nginx-ingress-controller. To add CIDR(s), leverage kubectl and run 

kubectl edit service nginx-ingress-controller -n domino-platform

Locate the section spec.loadBalancerSourceRanges to add the new CIDR(s).

  1. IMPORTANT: Communicate the CIDR(s) added to your deployment to Domino support so that future runs of the deployer will not revert your changes.

Rollback

In the case that you need to rollback the changes the steps are the reverse of those for applying the changes.

For Domino version 3.x and below

    1. In the AWS console remove the CIDR(s) from the following security groups for your VPC:
  • STAGE-general-admin
        1. Type: SSH, Protocol: TCP, Port Range: 22
        2. Type: All ICMP-IPv4 , Protocol: ICMP, Port range: All
      1. STAGE-domino_fe_ext_elb (this is labeled as STAGE-general-access in full Kubernetes deployments)
        1. Type: HTTP, Protocol: TCP, Port range: 80
        2. Type: HTTPS, Protocol: TCP, Port range: 443
  • STAGE-executor
      1. Type: Custom TCP, Protocol: TCP, Port range: 9000
      2. Type: Custom TCP, Protocol: TCP, Port: 49000-49999
      3. Type: SSH, Protocol: TCP, Port range: 22
    1. STAGE-domino_fe_int (skip if it doesn’t exist)
      1. Type: HTTP, Protocol: TCP, Port range: 80
      2. Type: HTTPS, Protocol: TCP, Port range: 443
      3. Type: Custom TCP, Protocol: TCP, Port range: 9000

  1.  
    1. Login to the salt master and edit /srv/pillar/custom/overrides.sls and look for sections access and admin_cidr and remove the CIDR(s) from each section where it appears.
    2. Verify the ELBs are present in the deployment either through the AWS console or by running the command

      kubectl get svc | grep traefik-ing

    3. Next, go to the directory /domino/k8s. There are two files here, traefik-ingress-external.yaml and traefik-ingress-internal.yaml corresponding to the two Kubernetes Elastic Load Balancers.
      Update both of these files to remove the CIDR(s) and then apply the changes with

      kubectl apply -f traefik-ingress-external.yaml
      kubectl apply -f traefik-ingress-internal.yaml

  2. IMPORTANT: Communicate the CIDRs removed from your deployment to Domino support so that future runs of the deployer will not revert your changes.

For Domino versions 4.x and above

    1. In the AWS console remove the CIDR(s) from the following security groups for your VPC:
  • STAGE-general-admin
        1. Type: SSH, Protocol: TCP, Port Range: 22
        2. Type: All ICMP-IPv4 , Protocol: ICMP, Port range: All
  • STAGE-general-access
      1. Type: HTTP, Protocol: TCP, Port range: 80
      2. Type: HTTPS, Protocol: TCP, Port range: 443
    1. STAGE-domino_fe_int (skip if it doesn’t exist)
      1. Type: HTTP, Protocol: TCP, Port range: 80
      2. Type: HTTPS, Protocol: TCP, Port range: 443
      3. Type: Custom TCP, Protocol: TCP, Port range: 9000

  1. Login to a node that can run kubectl. The primary Kubernetes security group for general access is controlled by the nginx-ingress-controller. To remove CIDR(s), leverage kubectl and run 

kubectl edit service nginx-ingress-controller -n domino-platform

Locate the section spec.loadBalancerSourceRanges to remove the CIDR(s).

  1. IMPORTANT: Communicate the CIDRs removed from your deployment to Domino support so that future runs of the deployer will not revert your changes.



Related articles

Comments

0 comments

Please sign in to leave a comment.