Gitlab pipeline creation

Gitlab groups user permissions

Gitlab project basics

Gitlab user provisioning ssh keys setup

Gitlab installation using vagrant

[Solved] Unknown configuration section 'hostmanager'

Recently working with the vagrant I came across this issue of 

Issue:-

Unknown configuration section 'hostmanager'

Cause:-

I have defined the hostmanager in my Vagrantfile but its an additional plugin which you need to install first before you can make the use of it.

Resolution:-

Run the following command to resolve this issue

 vagrant plugin install hostmanager  

Authorising AWS using temporary credentials from a role

Using the Access and secret key can result in a significant security issues if compromised.

So its better to use the role based authentication instead. But running the scripts might not be that easy with the role. So you can use the temporary credentials which are valid for 15minutes created by the role and authenticate the aws services.

This can come in handy while configuring the jobs in jenkins , running shell scripts etc.

So below is the process of how to achieve this.

 aws sts assume-role --role-arn arn:aws:iam::189786521149:role/ec2fullpermission --role-session-name "Session1" --profile prod2 > temp-creds.txt  
 # set the temporary credentials as the default AWS credentials in your console session  
 export AWS_ACCESS_KEY_ID=`cat temp-creds.txt | grep -w AccessKeyId | awk '{print $2}' | sed 's/"//g;s/,//g'`  
 export AWS_SECRET_ACCESS_KEY=`cat temp-creds.txt | grep -w SecretAccessKey | awk '{print $2}' | sed 's/"//g;s/,//g'`  
 export AWS_SECURITY_TOKEN=`cat temp-creds.txt | grep -w SessionToken | awk '{print $2}' | sed 's/"//g;s/,//g'  

Container Security

Usually when deploying a network for the application it flows like below

Internet (User) Network ----> DMZ (demilitarized zone) ----> Internal Network

Internet (User) Network :- Usually all the web applications receives request over the Internet from the end users.

DMZ (demilitarized zone) :- This is a isolation from the internal network and usually the webservers/Loadbalancers comes under this network so it only proceeds to internal network when user is logged and verified to be a genuine request. In cloud usualy loadbalancers are deployed in public subnet and webservers can than reside in private subnet.

Internal Network :- This is the private network which comprises of the application servers and the database servers. So webservers cant connect directly to the database servers they have to interact with the application servers first and application servers connect with the database servers.

Understanding Cloud Agreements

It is important to understand the components of the Cloud Agreement.

There are majorly two important cloud service agreements which are as follows

1. Acceptable Use Policy (AUP)

2. Service Level Agreements (SLA)

1. Acceptable Use Policy (AUP) :-

Acceptable use policy should be implemented in on-premise solutions to educate the users regarding the accepted and prohibited actions which can be taken for those systems.

AUP thus can be used by the cloud service provider, to release of any legal liability in the case that unlawful actions are carried out in the cloud environment by the customer.

AUP policies mostly describe about the violations to the AUP policy itself and describes about the punitive actions which can be taken if the AUP is not implemented or practiced. Usually if the AUP is violated than it may negatively impact the reputation of the CSP(Cloud service provider).

For eg:- Any type of vulnerability scanner software can't be run in the cloud.

2. Service Level Agreement(SLA):-

This document outlines all the services which are provided by the CSP to their customers and could include vital information which may affect the solutions deployed in the cloud directly like Availability, Serviceability, Performance. These SLA would usually provide the thresholds and financial repercussions associated with not meeting those thresholds. Well designed SLA would help resolve conflicts between the provider and the customer.

These can be created and identified by collecting and monitoring the key metrics. Usually CSPs doesn't provide this by default and customer needs to ask for them specifically , the burden of proof is on the customer if they want to push against SLA violations.

SLAs are  often non-negotiable documents that strictly limit the liability of the provider.