DevOps for Bangladeshi Fintech organization

Fintech is highly regulated segment in every country. Bangladeshi fintech is also the same which becomes a major constraints in leveraging latest technology capacity. One of the top 2 Banks in Bangladesh were also very keen to leverage the cloud service capacity to manage their internal developed projects. In that direction, they wanted to have CI/CD capacity for all of their internal projects. Since all of their resources are in private network capacity, a number of challenges came up which are not applicable for standard environment. I have shared few challenges below:

  1. No internet access to the environment and they won’t allow the internet for any case in this CI/CD process
  2. No access to the client’s servers by us.
  3. On-premise outdated gitlab repo servers
  4. Their existing deployment process is completely manual

To address the above challenges, we had to align all the activities which are aligned with their compliances/restrictions.

A step by step process has been prepared below:

Step 1: Create an IAM user for the on-premises instance.

Create an IAM user that the on-premises instance will use to authenticate and interact with CodeDeploy. No need to apply for any permission at this stage.

Step 2: Assign permissions to the IAM user

Assing the following AWS managed policies to the newly created user.

  1. AWSCodeDeployFullAccess
  2. AmazonS3ReadOnlyAccess

Step 3: Create Access Key and download it like below

Step 4: Add a configuration file to the on-premises instance

Add a configuration file to the on-premises instance, using root or administrator permissions. This configuration file will be used to declare the IAM user credentials and the target AWS region to be used for CodeDeploy. The file must be added to a specific location on the on-premises instance. The file must include the IAM user’s ARN, secret key ID, secret access key, and the target AWS region. The file must follow a specific format.

  1. Create a file named codedeploy.onpremises.yml in the following location on the on-premises instance: /etc/codedeploy-agent/conf
  2. Use a text editor to add the following information to the newly created codedeploy.onpremises.yml file:

aws_access_key_id: secret-key-id

aws_secret_access_key: secret-access-key

iam_user_arn: iam-user-arn

region: supported-region

     3. Under the following directory (/etc/codedeploy-agent/conf) edit codedeployagent.yml file and set proxy URL as below

:proxy_uri: https://username:password@proxy-domain-name:proxy-port

Step 5: Install and configure the AWS CLI

  1. Install AWS CLI from here.
  2. Configure AWS CLI as below

aws configure

AWS Access Key ID [None]: you access key Id

AWS Secret Access Key [None]: your secret key

Default region name [None]: supported-region

Default output format [None]: json

Step 6: Set the AWS_REGION environment variable

export AWS_REGION=supported-region

Step 7: Install the CodeDeploy agent

Install the CodeDeploy agent on the on-premises instance:

For ubuntu:

sudo apt-get update

sudo apt-get install ruby2.0 (Ubuntu Server 14.04) or sudo apt install ruby-full (16.04 or later).

sudo apt-get install wget

cd /home/{username}

wget https://aws-codedeploy-{region}.s3.amazonaws.com/latest/install

chmod +x ./install
sudo ./install auto (Ubuntu Server 14.04, 16.04, and 18.04)

 or sudo ./install auto > /tmp/logfile (for Ubuntu 20.04).

For Amazon Linux or RedHat

sudo yum update
sudo yum install ruby
sudo yum install wget
wget https://aws-codedeploy-{region}.s3.amazonaws.com/latest/install
chmod +x ./install
sudo ./install auto

Step 8: Register the on-premises instance with CodeDeploy from your local machine.

You need to install and configure AWS CLI on your local machine and your user must have the required permission to register the on-premises instance and tag it.

Find out the ARN of the user you have created in step 1 and register the deploy using the following command:

aws deploy register-on-premises-instance –instance-name AssetTag12010298EX –iam-user-arn arn:aws:iam::444455556666:user/CodeDeployUsername

Step 9: Tag the on-premises instance

You can use either the AWS CLI or the CodeDeploy console to tag the on-premises instance. (CodeDeploy uses on-premises instance tags to identify the deployment targets during a deployment.)

If you want to register from the CLI, use the following command

aws deploy add-tags-to-on-premises-instances –instance-names AssetTag12010298EX –tags Key=Name,Value=CodeDeployDemo-OnPrem

Step 11: Track deployments to the on-premises instance

After you deploy an application revision to registered and tagged on-premises instances, you can track the deployment’s progress.

Networking

Client needs to ensure the following:

  • Client’s internal Gitlab server can access AWS over site-to-site VPN
  • Target deployment server (where code deploy agent will be installed) can access AWS over site-to-site VPN
  • Target deployment server (where code deploy agent will be installed) can access proxy server hosted on AWS (IP: 10.35.5.30, PORT: 3128) over site-to-site VPN
  • Internet access on Target deployment server to install code deploy agent and AWS CLI

VPC configuration:

  1. Configure VPC named as ‘VPC The CBL’ taking IP address block from Client On-premise end. IP address 10.35.5.0/24
  2. Create 4 subnets in two Availability zones and define their IP address.
    1. VPC The CBL – Private – AZ1          10.35.5.0/28      
    1. VPC The CBL – Public – AZ1            10.35.5.16/28
    1. VPC The CBL – Private – AZ2          10.35.5.32/28
    1. VPC The CBL – Public – AZ2            10.35.5.48/28
  3. The default route table defined and renamed as private route table and associate it to all private(two) subnets.
    1. VPC The CBL – Private – AZ1          10.35.5.0/28
    1. VPC The CBL – Private – AZ2          10.35.5.32/28
  4. Create public route table and associate it to all public subnets
    1. VPC The CBL – Public – AZ1            10.35.5.16/28
    1. VPC The CBL – Public – AZ2            10.35.5.48/28
  5. Create Internet gateway (IGW) attached to VPC
  6. Add a route in public route table for destination 0.0.0.0/0 select target IGW.

AWS to The Client On-premise Site-to-Site VPN configuration:

  1. Create file for VPN checklist and take input from BS23 and The Client On-premise end.
  1. Create Customer gateway named as The CBL CGW with IP address 103.29.105.4.
  2. Create Virtual Private gateway named as The CBL VGW and attached to VPC The CBL.
  3. Configure Site-To-Site VPN name as AWS-To-The CBL using bellow information:
    1. Target gateway type –> Virtual private gateway–>The CBL VGW
    1. Customer gateway–> Existing—> The CBL CGW
    1. Routing options —>Static and add Static IP prefixes —> 192.168.98.16/28
    1. Local IPv4 network CIDR –> 192.168.98.16/28
    1. Remote IPv4 network CIDR–> 10.35.5.0/24
  4. Download the configuration file for Cisco Firepower ikev1 and share it with the client Team.
  5. Enable route propagation for both private and public subnets.

Configure VPC endpoint for accessing AWS CodeCommit :

  1. Create endpoint as
    1. Name tag: AWS CodeCommit
    1. Service category: AWS services
    1. Filter Services: com.amazonaws.ap-southeast-1.git-codecommit
    1. Select VPC: The CBL VGW
    1. Select private Subnets:
      1. ap-southeast-1a (apse1-az1)
      1. ap-southeast-1b (apse1-az2)
    1. IP address type: IPv4
    1. Security groups: AWS CodeCommit configured as all inbound and outbound traffic allow.
    1. From Additional settings
      1. Select:  Enable DNS name
      1. DNS record IP type: IPv4
    1. Policy: full access.

VPC endpoint for AWS CodeCommit: vpce-07bec13f9640d9eee-yrnxfw8a.git-codecommit.ap-southeast-1.vpce.amazonaws.com

Launch an EC2 instance for creating proxy server:

Install Squid and configure Proxy server:

  • Install Squid.

root@prox:~# apt -y install squid

  • This is common forward proxy settings.

root@prox:~# vi /etc/squid/squid.conf

  • acl CONNECT method CONNECT

# line 1209: add (define ACL for internal network)

acl my_localnet src 192.168.98.16/28

  • # line 1397: uncomment

http_access deny to_localhost

  • # line 1408: comment out and add the line (apply ACL for internal network)

#http_access allow localhost

http_access allow my_localnet

  • # line 5611: add

request_header_access Referer deny all

request_header_access X-Forwarded-For deny all

request_header_access Via deny all

request_header_access Cache-Control deny all

  • # line 8264: add

# forwarded_for on

forwarded_for off

  • root@prox:~# systemctl restart squid

Set Basic Authentication and limit Squid for users to require authentication.

  • Install a package which includes htpasswd.

root@prox:~# apt -y install apache2-utils

  • Configure Squid to set Basic Authentication.

root@prox:~# vi /etc/squid/squid.conf

  • acl CONNECT method CONNECT

# line 1209: add follows for Basic auth

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/.htpasswd

auth_param basic children 5

auth_param basic realm Squid Basic Authentication

auth_param basic credentialsttl 5 hours

acl password proxy_auth REQUIRED

http_access allow password

  • root@prox:~# systemctl restart squid
  • # add a user : create a new file with [-c] option

root@prox:~# htpasswd -c /etc/squid/.htpasswd bs23

New password:     # set password

Re-type new password:

Adding password for user bs23

Proxy server information:

IP: 10.35.X.X

port: 3128

user: username

pass: password

The above process helped the client to have better efficiency and predictable flow in their DevOps process.

Leave a comment