DevOps – Blog TheExpert https://theexpert.squad.fr/theexpert Blog TheExpert Sun, 29 Aug 2021 06:13:50 +0000 fr-FR hourly 1 #TheExpert – Saro, directeur de Squad#Nord https://theexpert.squad.fr/theexpert/digital/devops/theexpert-saro-directeur-de-squadnord/ https://theexpert.squad.fr/theexpert/digital/devops/theexpert-saro-directeur-de-squadnord/#respond Mon, 23 Aug 2021 12:32:48 +0000 https://theexpert.squad.fr/theexpert/?p=16574 À l’approche du FIC2021, lumière sur Saro KAMBER, Directeur de la région Nord. Il a rejoint Squad en début d’année et a de très grands projets pour cette région. Parcours, visions du marché et ambitions pour 2025, il nous dit tout dans cet interview. Peux-tu te présenter ? Que faisais-tu avant de rejoindre Squad ? […]

L’article #TheExpert – Saro, directeur de Squad#Nord est apparu en premier sur Blog TheExpert.

]]>
À l’approche du FIC2021, lumière sur Saro KAMBER, Directeur de la région Nord. Il a rejoint Squad en début d’année et a de très grands projets pour cette région. Parcours, visions du marché et ambitions pour 2025, il nous dit tout dans cet interview.

Peux-tu te présenter ? Que faisais-tu avant de rejoindre Squad ?

Je suis arrivé chez SQUAD en tout début d’année 2021. J’ai une vingtaine d’années d’expérience, j’en ai fait la moitié en direction opérationnelle au sein des DSI, et puis l’autre moitié dans des cabinets de conseil. D’abord, dans l’innovation digitale, puis dans la transformation agile et aujourd’hui dans la cybersécurité et le développement.

Quels sont les grands enjeux de la région parisienne ?

L’agence de Paris a été fondée il y a trois ans et le secteur de la cybersécurité en général a connu une forte croissance ces dernières années, mais ce n’est rien comparé à ce qu’on a connu en 2020 et en 2021. Là, les besoins ont littéralement explosé, on s’est rendu compte que les grands clients, qui sont essentiellement les acteurs de la banque de la finance, de l’assurance ou les gouvernements européens, ont besoin de protéger leurs données et de s’assurer que la réputation de leurs marques soit respectée.

C’était une opportunité pour SQUAD et plus précisément pour Paris car la majorité des sièges des grands groupes sont dans la région parisienne, et par conséquent, il y a un potentiel, de notre point de vue, presque infini.

La raison pour laquelle on a renforcé les équipes (le staff parisien et lillois) dont on parlera tout à l’heure, c’est parce qu’on a une vraie conviction : les enjeux de la cybersécurité et du DevOps se passent dans la région parisienne.

Aujourd’hui, on a une dizaine de personnes qui composent le staff pour tenir la relation client et la relation avec nos talents, et pour aller chercher les meilleurs talents sur le marché. Nous sommes en train aussi d’ouvrir Lille qui est l’une des terres de croissance de la CyberSécurité et du DevOps en France.

Comment se positionne Squad dans cette région ?

Les deux terres de croissance de la région nord sont Paris et Lille, et à l’intérieur de ça, les véritables questions sont : Quelle est notre valeur ajoutée ? Quel est notre positionnement ? Qu’est-ce qu’on peut apporter ?Pourquoi on arrive à prendre ce train en marche ? En réalité, quand on regarde le marché de la cybersécurité, la vraie difficulté c’est la tension du marché sur les talents, la difficulté à trouver les bons talents.

Aujourd’hui, on a une conviction. D’abord, Squad s’est transformé pour être capable d’aller attirer les meilleurs talents et les meilleurs experts du marché pour les faire venir chez nous et pouvoir délivrer à nos clients les meilleures prestations.

Puis aussi, deux autres catégories. La première, ce sont les nouveaux diplômés qui possèdent déjà une expertise et qui sont passionnés par leur domaine à qui on offre des opportunités pour travailler dans les grands groupes et pour réaliser de très belles choses d’ailleurs.

La seconde catégorie regroupe les experts qui sont en reconversion, alors reconversion ce n’est pas péjoratif au contraire, ce sont des gens qui ont bien compris la transformation du marché les attentes du marché qui se sont dits : ” la cybersécurité, j’y crois, j’en ai envie, je vais y aller “.

De nos jours, Squad Paris et Squad Lille exploitent avec sa Squad Academy (parcours d’apprentissage et de formation) se positionnent comme un partenaire de nos experts pour leur apprendre les nouvelles méthodologies, pour leur faire acquérir les nouvelles compétences, pour leur faire comprendre les nouvelles normes et faire de ces collaborateurs-là, les experts de demain.

C’est un peu ça la réussite de SQUAD dans son modèle, c’est cette capacité à mettre à disposition à l’ensemble de ses clients, les meilleurs experts du marché, ou en tout cas, s’il ne les a pas à l’instant T, d’être capable de les former pour demain.

Squad#2025, en chiffres, ça donne quoi ?

Les chiffres sont très intéressants, ils reflètent aussi la réalité de notre marché. En 2021, Squad prévoit de faire 65 millions d’euros de chiffre d’affaires et d’avoir 700 talents dans ses effectifs.

Quand on se projette à plusieurs années, en lien avec la croissance du marché et les opportunités qui s’ouvrent, on estime qu’on peut en 2025 avoir 1500 talents et réaliser 200 millions d’euros de chiffre d’affaires.

Ce qui veut dire quand même que le potentiel est gigantesque pour une société comme Squad qui a été fondée il y a moins de dix ans.

Retrouvez la Squad#Family au FIC du 7 au 9 septembre ⤵

L’article #TheExpert – Saro, directeur de Squad#Nord est apparu en premier sur Blog TheExpert.

]]>
https://theexpert.squad.fr/theexpert/digital/devops/theexpert-saro-directeur-de-squadnord/feed/ 0
Squad#Experience – Amaïa s’est autoformée pour devenir DevOps https://theexpert.squad.fr/theexpert/devops-2/squadexperience-amaia-sest-autoformee-pour-devenir-devops/ https://theexpert.squad.fr/theexpert/devops-2/squadexperience-amaia-sest-autoformee-pour-devenir-devops/#respond Tue, 27 Jul 2021 07:46:20 +0000 https://theexpert.squad.fr/theexpert/?p=16509 Amaïa a rejoint la Squad#Family il y a un peu plus d’un an. Elle nous raconte son parcours professionnel et comment elle est devenue DevOps ! Peux-tu te présenter, notamment ton parcours professionnel ? Je m’appelle Amaïa, Consultante infrastructure DevOps chez Squad depuis février 2020. Je travaille essentiellement sur des sujets DevOps avec une orientation […]

L’article Squad#Experience – Amaïa s’est autoformée pour devenir DevOps est apparu en premier sur Blog TheExpert.

]]>
Amaïa a rejoint la Squad#Family il y a un peu plus d’un an. Elle nous raconte son parcours professionnel et comment elle est devenue DevOps !

Peux-tu te présenter, notamment ton parcours professionnel ?

Je m’appelle Amaïa, Consultante infrastructure DevOps chez Squad depuis février 2020. Je travaille essentiellement sur des sujets DevOps avec une orientation dans l’automatisation. J’ai un parcours assez atypique parce que j’étais développeuse auparavant. J’ai fait une formation quand je travaillais dans une autre entreprise. Je me suis rendu compte que j’étais assez intéressée par l’infrastructure, et le DevOps.

Chez moi, en autoformation, je me suis montée des projets orientés DevOps. J’ai commencé à toucher à des nouvelles technologies comme Docker ou Linux.

De cette façon, j’ai su que j’étais faite pour ça et j’ai intégré Squad. J’ai fêté il y a quelque jour ma première année chez Squad !

Quelle est ta mission actuelle ?

À l’heure actuelle, je suis en mission pour un grand compte de la Défense sur des sujets d’automatisation et de DevOps. Mon client avait besoin d’automatiser une infrastructure en pleine refonte.

Avant de produire, j’étais amenée à participer à la structuration du projet comme la mise en place des processus et de la documentation. C’était vraiment la phase de construction de projet.

Ensuite, j’ai commencé à produire. Les outils que j’utilise le plus sont Ansible et Ansible Tower, de la solution RedHat Automotion plateform, et aussi GitLab.

Grâce à mes compétences de développeuse, je travaille avec la technologie Git. Ces compétences me servent donc tous les jours.

En ce moment, passes-tu des formations ou envisages-tu d’en passer ?

À l’heure actuelle, je suis en autoformation sur la certification RHCSA de Red Hat qui me permet d’acquérir les compétences fondamentales de l’administration système, côté Linux.

J’ai plutôt bien avancé, j’ai prévu de la passer cette année.

J’envisage de m’autoformer sur la DevOps Foundation de la DevOps Institute. Pour moi, cette certification est très importante, car elle me permet d’acquérir plus de méthodologie, de mieux comprendre les enjeux, les pratiques et la connaissance des outils par rapport au DevOps.

Très souvent, on se focalise sur les outils, quand on fait du DevOps, mais ce n’est pas que les outils c’est aussi une méthodologie.

Découvrez les parcours de nos Experts ⤵

L’article Squad#Experience – Amaïa s’est autoformée pour devenir DevOps est apparu en premier sur Blog TheExpert.

]]>
https://theexpert.squad.fr/theexpert/devops-2/squadexperience-amaia-sest-autoformee-pour-devenir-devops/feed/ 0
AWS S3M Pattern: Terraform & DevOps for a 10 Years Child https://theexpert.squad.fr/theexpert/digital/devops/aws-s3m-pattern-terraform-devops-for-a-10-years-child/ https://theexpert.squad.fr/theexpert/digital/devops/aws-s3m-pattern-terraform-devops-for-a-10-years-child/#respond Mon, 26 Jul 2021 08:00:27 +0000 https://theexpert.squad.fr/theexpert/?p=16492 By Naoufal E., Squad Experts “Tricks make you save time to Code & Deploy your Terraform Config File Easily” As a Software Architect or a FullStack-Developer (someone with a developer background), I always had this fear of the syntax of Terraform configurations (HashiCorp Configuration Language: HCL). Every time I read an example of a file […]

L’article AWS S3M Pattern: Terraform & DevOps for a 10 Years Child est apparu en premier sur Blog TheExpert.

]]>
By Naoufal E., Squad Experts

“Tricks make you save time to Code & Deploy your Terraform Config File Easily”

As a Software Architect or a FullStack-Developer (someone with a developer background), I always had this fear of the syntax of Terraform configurations (HashiCorp Configuration Language: HCL).

Every time I read an example of a file with this syntax I couldn’t understand anything and I didn’t know why.

However, I figured out why: “it was because my brain was formatted or programmed about how to design software, how to make an algorithm to solve a problem, etc … And nothing else”, so I tried to understand the Terraform config file with this mindset and I complicated my understanding of a simple configuration language (HCL),

I wrote this story to share with you Tips & Tricks for a better understanding and deploying Terraform by implementing S3M Pattern that I wrote before.

To understand better the implemented example, please refer to my previous story

Prerequisite:

→ AWS Account

→ AWS Programatically Acount with Programmatic access and Admin Permission

→ AWS CLI configured in your laptop (if you want to run your infra from you laptop (~/.aws/config )

→ A better understanding of S3M Pattern

Terraform: What? Why? How?

What Is Terraform?

Is an IaC Software Tool 😲 →Infra as Code Software Tool 😳→ A software that allows us to code our InfraStructure 😜.

Coding infra may be done with two methods: Imperative (How) or Declarative (What) or both together.

Imperative :

  • Focuses on How the infrastructure must be done
  • Defines specific commands that need to be executed in the appropriate order to end with the desired conclusion

Declarative :

  • Focus on What the eventual target configuration should be
  • Defines the Desired State and the system executes what needs to happen to achieve that Desired State

And Terraform is Declarative, so now you know why as a software architect, I complicated things, my mind was always focusing on How (always designing how), but if you need to understand easily Terraform you should switch your mind on What and everything will become too easy 😉

Why should we use it?

Terraform makes a great tool when it comes to DevOps & Portability. There are the reasons to consider Terraform as one of your IaC tools :

  • Portability: This is the big problem that Terraform Solves: it makes it easy to Duplicate Infra in different environments (DEV, PRE, PROD) at the same Cloud Provider. Also and because Terraform is completely platforms agnostic, it facilitates the coding resources of the new Cloud Provider if the company decides to change it Cloud Provider.
  • Terraform lets you define infrastructure in a config file and will enable you to track changes to infrastructure with ease by having your code in source control (Git), building it, and deploying it.
  • Terraform has a lively community and is open source, there is a massive community developing around this tool. Many people are already using it, and it’s easier to find people who know how to use it, plugins, extensions, professional support, etc. This also means Terraform is evolving at a much faster rate. They do releases very often.
  • Terraform’s speed and operations are exceptional. One cool thing about Terraform is, its plan command lets you see what changes you’re about to apply before you apply them.

How to Use it?

# Declare wish provider you want to use
provider "aws" {
   region = "us-east-2"
}
# Declare a VPC
resource "aws_vpc" "s3m-vpc" {
    cidr_block = "10.0.0.0/16"
    enable_dns_hostnames = true
     tags = {
    "project" = "S3M"
    "tuto"="medium"
  }
}

In the same folder open a terminal and run these commands

terraform init

This command is to download all dependencies for your cloud provider (like npm install or dotnet restore for developers lol )

terraform plan 

This command is for creating an execution plan. Terraform performs a refresh, unless explicitly disabled, and then determines what actions are necessary to achieve the desired state specified in the configuration files.

You can skip this command and apply directly your IaC, but is recommended to see what you have in your plan and fix errors or bugs before applying your infra

terraform apply

The terraform apply command is used to apply the changes required to reach the desired state of the configuration, or the pre-determined set of actions generated by a terraform plan execution plan.

  • You can now go to your account and verify if the VPC is created in the us-east-2 region
  • And finally, to destroy what are you created, you can run this command :
terraform destroy

Tips to implement Terraform on Complex Architectures

In this section, I’ll give you some tips & tricks to save your time when coding the infra of a Complex Architecture.

As an example, we will take the S3M Pattern that I wrote before. As a reminder this the architecture :

Terraform With DevOps explained to a 10 Years Child — S3M Pattern
S3M Pattern

AWS S3M Pattern: 5 Steps to marry Serverless & Microservice Securely“Save your time with this Abstract Pattern to make complex Cloud Architectures”naoufal-gafa.medium.com

Tip 1: To-Do Liste of What we want 😜 :

As you can see, for this pattern we need these blocks:

  1. VPC with three subnets (two privates and one public)
  2. APIGateway with VPC Link
  3. Authorizer (Lambda and API Gateway)
  4. ECS Cluster Fargat with TaskDefinition and Service
  5. NLB (Network Load Balancer with a TargetGroup)
  6. S3 For Static Web Site Hosting

Tip 2: Create a *.tf file for each block😄:

  1. vpc.tf
  2. api-gateway.tf
  3. authorizer.tf
  4. cluster.tf
  5. load-balancer.tf
  6. s3.tf
  7. To properly organize our code, we can make also a folder for different policies (JSON files)

Tip 3: The Magic of Copy-Past 😅

  1. Open the Terraform Documentation for AWS
  2. For each file: copy-past the configuration and adapt it like the image below:
Terraform With DevOps explained to a 10 Years Child — filter

So, for example, the vpc.tf file will look like this if we implement it with the S3M Pattern:

# Declare a VPC
resource "aws_vpc" "s3m-vpc" {
    cidr_block = "10.0.0.0/16"
    enable_dns_hostnames = true
     tags = {
    "project" = "S3M"
    "tuto"="medium"
  }
}

# Declare all availabilities zones.
# Declare 1st Availability Zone
resource "aws_subnet" "s3m-public" {
    vpc_id = aws_vpc.s3m-vpc.id
    cidr_block = "10.0.1.0/24"
    availability_zone = var.availability_zone_1
     tags = {
    "name"="s3m-public"
    "project" = "S3M"
    "tuto"="medium"
  }
}
# Declare 2nd Availability Zone
resource "aws_subnet" "s3m-private-1" {
    vpc_id = aws_vpc.s3m-vpc.id
    cidr_block = "10.0.2.0/24"
    availability_zone = var.availability_zone_2
    tags = {
    "name"="s3m-private"
    "project" = "S3M"
    "tuto"="medium"
  }
}
# Declare 3rd Availability Zone
resource "aws_subnet" "s3m-private-2" {
    vpc_id = aws_vpc.s3m-vpc.id
    cidr_block = "10.0.3.0/24"
    availability_zone = var.availability_zone_3
    tags = {
    "name"="s3m-private"
    "project" = "S3M"
    "tuto"="medium"
  }
}

# Declare the Internet Gateway
resource "aws_internet_gateway" "s3m-igw" {
    vpc_id = aws_vpc.s3m-vpc.id
}

# Declare the elastic IP for the nat Gateway
resource "aws_eip" "s3m-eip_nat_gateway" {
  vpc = true
}

# Declare the Nat Gateway
resource "aws_nat_gateway" "s3m-ngw" {
  allocation_id = aws_eip.s3m-eip_nat_gateway.id
  subnet_id     = aws_subnet.s3m-public.id
  tags = {
    "project" = "S3M"
    "tuto"="medium"
  }
}

# Update the defaultroute table
resource "aws_default_route_table" "s3m-rt-public" {
default_route_table_id = aws_vpc.s3m-vpc.default_route_table_id
route {
        cidr_block = "0.0.0.0/0"
        gateway_id = aws_internet_gateway.s3m-igw.id
    }
}

# Declare a private route table for private networks
resource "aws_route_table" "s3m-rt-private" {
    vpc_id = aws_vpc.s3m-vpc.id
    route {
        cidr_block = "0.0.0.0/0"
        nat_gateway_id = aws_nat_gateway.s3m-ngw.id
    }
}

# Declare the association between private subnets and private route table
# First Private Subnet
resource "aws_route_table_association" "s3m-rta-private-1" {
    subnet_id = aws_subnet.s3m-private-1.id
    route_table_id = aws_route_table.s3m-rt-private.id
}


# Second Private Subnet
resource "aws_route_table_association" "s3m-rta-private-2" {
    subnet_id = aws_subnet.s3m-private-2.id
    route_table_id = aws_route_table.s3m-rt-private.id
}

If you are asking: what about the fulfillment’s order ?! Should we start with VPC, ECS, APIGateway or…?

Answer : Is not your problem 😝, you don’t need to care about this😃, your job is to Describe, and Terraform Job is to Define the best way to execute your staff 😉

DevOps Philosophy

Definition

What is really DevOps? DevOps is not a job title 😠, in fact, it is a set of practices that combines software development (Dev) and IT operations (Ops).

DevOps initiatives can create cultural changes in companies by:

  • Transforming the way operations, developers, and testers collaborate during the development and delivery processes 😃.
  • Getting these groups to work cohesively is a critical challenge in enterprise DevOps adoption 😃.
  • DevOps is as much about the culture, as it is about the toolchain.

So when some companies are looking for a DevOps engineer within their workflows, it means that they are not ready to change their philosophy and culture, and this may just deepen the disconnect between developers and operational teams 😅.

Toolchains

DevOps tools fit into one or more activities, which supports specific DevOps initiatives: Plan, Create, Verify, Package, Release, Configure, Monitor, and Version Control. For more info click here

I’ll keep it simple in this story by focusing on these tools: Create (Code)Package (Artifact)Release (Deploy)Configure (IaC), Version Control.

Automatize all with GitHub Actions: (Get your Hands Dirty)

Now that you know what are Terraform DevOps about, let make some automatization to PackageRelease and Configure the delivery process of the Backend, FrontEnd, and IaC (Config) with GitHub Actions

GitHub Actions makes it easy to automate all our software workflows with CI/CD. we will use it to PackageRelease, and Configure our code right from GitHub.

Prerequisites:

→ GitHub Account: you will need a GitHub account to clone my repo examples in yours to automatize and build pipelines

→ Terraform Free Account: Explained in IAC Repository below

For the automatization I make 3 Pipeline, one for each Repository:

  1. IaC Repository
  2. API Repository
  3. Static Web Site Repository

As you can see, for each Repo I have a Yaml file that exists in /.github/workflows. This file will be interpreted by the Action Workflow of GitHub to run a pipeline that builds and deploys.

All Yaml files are well commented for a better understanding 😃

  1. For IaC: The pipeline will simply apply our infra
  2. For API: The pipeline will containerize our package in a docker image and push it to Ecr Repo
  3. For Static web Site: The pipeline will build our Angular project and deploy it to S3 Static web Hosting

IaC Repository :

To automatize the deployment of your Terraform IaC code, firstly you should create a free account with Terraform and follow these steps.

1- Create Your Organization

Terraform With DevOps explained to a 10 Years Child — S3M Pattern — Terraform Organization
Terraform organization

Once the organization created, it’s time to create the workflow

2- Create The Workflow

To do so, click on API-driven workflow as shown in the image below and create your workflow

Terraform With DevOps explained to a 10 Years Child — S3M Pattern — Terraform Worflow
Terraform Workflow

Name your workspace and create it

Terraform With DevOps explained to a 10 Years Child — S3M Pattern — Terraform Workspace
Terraform workspace

Once the workspace is created, terraform will generate for you this code to use in your main config file (main.tf) that exists in your repository.

So, copy-paste this code (a full example can be found in my repo)

terraform {
backend "remote" {
organization = "your organization name"workspaces {
name = "your workspace name"
}
}
}

3- Generate a Terraform Cloud User API token:

Terraform With DevOps explained to a 10 Years Child — S3M Pattern — Terraform User Token API
Terraform User API Token
  • Give it a description to help you identify this token later and click on “Create API token”
Terraform With DevOps explained to a 10 Years Child — S3M Pattern — Terraform Token
  • Copy the generated token
Terraform With DevOps explained to a 10 Years Child — S3M Pattern — Terraform Token
Terraform Generated Token

4- Store the generated token as a GitHub secret on the IaC Repository:

Terraform With DevOps explained to a 10 Years Child — S3M Pattern — Github secrets
Repo Secret

You can follow the GitHub Docs here.

5- Store the AWS Keys on Terraform Cloud Environment Variables :

We need to save our AWS Access Key and Secret Key on Terraform Environment Variable, so when the Github pipeline run, it will use these credentials to Plan and Apply our infra to the AWS Account.

To do so go to https://learn.hashicorp.com/tutorials/terraform/cloud-workspace-configure and follow the steps bellow

  • Add Environment Variables
Terraform With DevOps explained to a 10 Years Child — S3M Pattern — Terraform Environment Variables
Create Terraform Environment Variables
  • Create these two environment variables and make them sensitive:
Terraform With DevOps explained to a 10 Years Child — S3M Pattern — Terraform Environment Variables
Terraform Secrets

For more info about managing secrets on Terraform, you can follow this Blog

6- Run your pipeline on GitHub

Terraform With DevOps explained to a 10 Years Child — S3M Pattern — GitHub Pipeline
GitHub Pipeline

API Repository :

After the deployment of our Infrastructure, now it’s time to deploy our API, otherwise, the pipeline will simply push a docker image into ECR (that’s all 😄)

Don’t forget to add the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in the secret of your API Repository, and run the pipeline via the GitHub Action Tab

The full example can be found here

Terraform With DevOps explained to a 10 Years Child — S3M Pattern — Github Secrets
API Secrets

Static Web Site Repository :

Because we did not attach a custom domain name to our API Gateway we should copy the EndPoint generated by our IaC Deployment and past it to the environment variable of the Static Web Site

Another option more complicated is to store the environment variable in a Configuration Manager like (AWS secrets manager) or use a Cloud Agnostic Tools like SOPS

1- Go to your APIGateway Dashboard, click on the created API, go to Stages and copy the endpoint

Terraform With DevOps explained to a 10 Years Child — S3M Pattern — Api Gateway EndPoint
API Gateway EndPoint

2- Go to your Static WebSite Repository, update the environment file and make a commit

Terraform With DevOps explained to a 10 Years Child — S3M Pattern — S3 Front
Static Web Site Environment

3 – Run your Pipeline (Don’t forget to add the AWS_ACCESS_KEY_ID and  AWS_SECRET_ACCESS_KEY in the secret of your API Repository, and run the pipeline via the GitHub Action Tab)

4 – Check if everything works by going to your s3 static web site Endpoint, copying the link, pasting it to your browser, and clicking on the “Get weather” button

Terraform With DevOps explained to a 10 Years Child — S3M Pattern — S3 Link
S3 link
Terraform With DevOps explained to a 10 Years Child — S3M Pattern — Front check
Final Check

Greaaaaaaaaaat, everything automatized and worked like magic 😄

Conclusion

In real life, coding and managing the source code of the Infra is such a great thing because it allows the Company Architect to follow all changeset and apply only the changes without destroying all the infra architecture.

In real life, coding and managing the Infra source code is such a great thing as it allows the company architect to keep up with all the changes and apply only the necessary updates without destroying the entire system.

The IaC philosophy also facilitates the portability of the Infrastructures:

  • Between different clouds provider
  • Between different environment of the same cloud provider

When we tied IaC with real DevOps philosophy, we save much more the time of process delivery while keeping a better quality of code.

If you are new to these technologies (AWS, IaC, DevOps), this blog will help you understand the sequence of the different bricks (AWS, IaC, DevOps) and will prevent you from following many tutorials and going in all directions.

I wish to thank by the way Soufian Belehrache for his technical advice.

If you have any remarks, or if something doesn’t seem clear, please leave a comment or contact me on my Fb PageTwitter, or via my website

Finally, I have a challenge for you:

  • Create a GitHub account if you don’t already have one
  • Create a Terraform Free Account
  • Apply what are you learned in this Story “Section Automatize all with GitHub Actions: (Get your Hands Dirty)”
  • Good luck

See you at the next Story ✌.

References

L’article AWS S3M Pattern: Terraform & DevOps for a 10 Years Child est apparu en premier sur Blog TheExpert.

]]>
https://theexpert.squad.fr/theexpert/digital/devops/aws-s3m-pattern-terraform-devops-for-a-10-years-child/feed/ 0
Background on time series modeling and forecasting (2/3) https://theexpert.squad.fr/theexpert/digital/devops/background-on-time-series-modeling-and-forecasting-2-3/ https://theexpert.squad.fr/theexpert/digital/devops/background-on-time-series-modeling-and-forecasting-2-3/#respond Wed, 07 Jul 2021 11:58:27 +0000 https://theexpert.squad.fr/theexpert/?p=16407 Time series modeling carefully collects and studies the past observations expressed as a time series for the purpose of developing an appropriate model which describes the inherent structure of the series. One of the most frequently used stochastic time series models is the Autoregressive Integrated Moving Average (ARIMA), whose popularity is mainly due to its […]

L’article Background on time series modeling and forecasting (2/3) est apparu en premier sur Blog TheExpert.

]]>
Time series modeling carefully collects and studies the past observations expressed as a time series for the purpose of developing an appropriate model which describes the inherent structure of the series. One of the most frequently used stochastic time series models is the Autoregressive Integrated Moving Average (ARIMA), whose popularity is mainly due to its flexibility to represent several varieties of time series with simplicity.

Autoregressive Integrated Moving Average (ARIMA) process for univariate time series

ARIMA1 is a class of generalized model that captures temporal structure in time series data. For this purpose, ARIMA combines Auto Regressive process (AR) and Moving Average (MA) processes so as to build a composite model of the time series. In particular, ARIMA forecasts the next values using auto regression with some parameters fitted to the model. Then, AMIRA applies a moving average with a set of parameters. During the autoregression, the variable of interest  𝑦𝑡 is forecasted using a linear combination of past values of the variable 𝑦𝑡-1, 𝑦𝑡-2, … , αp𝑦𝑡-p. The Autoregressive term is written as:

𝑦𝑡 = c + α1𝑦𝑡-1+ α2𝑦𝑡-2 + … + αp𝑦𝑡-p + ε𝑡

where c is a constant, αi (i= 1, 2,…,p) is the model parameter that needs to be discovered, 𝑦𝑡-1(i= 1,2,…,p) are the lagged values of 𝑦t and ε𝑡 is the white noise.

The moving average term 𝑦𝑡 can be expressed based on the past forecast errors (rather than using past values): 

𝑦𝑡 = u + ϴ1 ε𝑡-1ϴ2 ε𝑡-2+ … + ϴq ε𝑡-q + ε𝑡

where u is a constant, ϴi (i= 1,2,…,q) are the model parameters, ε𝑡i are random shocks at time period t-i (i= 1,2,…,q) and ε𝑡 is white noise.

Overall, the autoregressive (AR), moving average (MA) and Integration models are effectively combined to form a class of time series models, called ARIMA (with 𝑦’𝑡 representing the differenced time series), which is expressed as:   

𝑦’𝑡 = c + α1𝑦𝑡-1+ α2𝑦𝑡-2 + … + αp𝑦𝑡p+ϴ1 ε𝑡-1ϴ2 ε𝑡-2 + … + ϴq ε𝑡-q + ε𝑡

An important prerequisite is to check whether a time series is stationary (constant mean and variance) through plotting and root testing using augmented Dickey-Fuller1 or Philips-Perron2 unit root test.  If the time series is not stationary, it can be made stationary by differencing the time series3.

The best parameters are found using the Box-Jenkins method4, which is a three-step approach that consists in:

  • identifying the model to ensure that the variables are stationary and selecting parameters based on the Autocorrelation Function (AFC)6 for the MA terms and the Partial Autocorrelation Function (PACF)5 for the AR terms.
  • estimating the parameters (α and ϴ) that best fit the ARIMA model based on e.g. maximum likelihoodor the nonlinear least square7. Among candidate models, the best suited model is the one that has the best AIC or BIC value 8.
  • Statistical model checking lying in studying if the residual is white noise and has a constant mean and variance over time. If these assumptions are not satisfied a more appropriate model needs to be fitted.

If all the assets are satisfied, the future values can be forecasted according to the model. The ARIMA model has been generalized by Box and Jenkins to deal with seasonality.

Seasonal Autoregressive Integrated Moving Average (SARIMA) process for univariate time series

Seasonal ARIMA (SARIMA)10 deals with a seasonal component in univariate time series. In addition to the autoregression (AR), differencing (I) and moving average (MA), SARIMA accounts for the seasonal component of the time series leveraging additional parameters for the period of the seasonality. The SARIMA model is hence represented as SARIMA(p,d,q)(P,D,Q)m where P defines the order of the seasonal AR term, D the order of the seasonal Integration term, Q the order of the seasonal MA term and M the seasonal factor.

Vector Autoregressive Integrated Moving Average (VARMA) process for multivariate time series

Contrary to the ARIMA model, which is fitted for univariate time series, VARMA(p,q)10 deals with  multiple time series that may influence each other. For each time series, we regress a variable on p lags of itself and all the other variables and so on for the q parameter. Given k time 𝑦𝑡-1, 𝑦𝑡-2, …, 𝑦kt series expressed as a vector V𝑡 = [𝑦𝑡-1, 𝑦𝑡-2, …, 𝑦kt] , VARMA(p,q) models is defined by the Var and Ma models:

Equation. 1 VARMA matrix notation

where ck matrix is a constants vector, α𝑡i,j  (i,j=\ 1,2,…,k) and ϴ ij (i,j=\ 1,2,…,k) matrixes are the model parameters and k is the number of time series, 𝑦k,𝑡-1(,i= 1,2,…,p) are the lagged values matrix and the cross variables dependency. εk,t-q (i= 1,2,…,q) are the matrix of random shocks and Φkt is white noise vector with zero mean and constant covariance matrix.

In the following, we will use this family of models to model and predict the behavior of the NVF/CNF system and detect anomalies.

If you have missed the first part, here you can read the introduction

References ⤵

  • [1] Dickey, D. A., & Fuller, W. A. (1979). Distribution of the estimators for autoregressive time series with a unit root. Journal of the American statistical association, 74(366a), 427-431
  • [2] Phillips, Peter & Perron, Pierre. (1986). Testing for a Unit Root in Time Series Regression. Cowles Foundation, Yale University, Cowles Foundation Discussion Papers. 75. 10.1093/biomet/75.2.335
  • [3] Nason, G. P. (2006). Stationary and non-stationary time series. Statistics in volcanology, 60.
  • [4] Box, G. E., Jenkins, G. M., Reinsel, G. C., & Ljung, G. M. (2015). Time series analysis: forecasting and control. John Wiley & Sons.
  • [5] Watson, P. K., & Teelucksingh, S. S. (2002). A practical introduction to econometric methods: Classical and modern. University of West Indies Press
  • [6] Myung, I. J. (2003). Tutorial on maximum likelihood estimation. Journal of mathematical Psychology, 47(1), 90-100.
  • [7] Hartley, H. O., & Booker, A. (1965). Nonlinear least squares estimation. Annals of Mathematical Statistics, 36(2), 638-650.
  • [8] Akaike, H. (1998). Information theory and an extension of the maximum likelihood principle. In Selected papers of hirotugu akaike (pp. 199-213). Springer, New York, NY.
  • [9] Hyndman, R. J., & Athanasopoulos, G. (2018). Forecasting: principles and practice. OTexts.
  • [10] Brockwell, P. J., Brockwell, P. J., Davis, R. A., & Davis, R. A. (2016). Introduction to time series and forecasting. springer.

L’article Background on time series modeling and forecasting (2/3) est apparu en premier sur Blog TheExpert.

]]>
https://theexpert.squad.fr/theexpert/digital/devops/background-on-time-series-modeling-and-forecasting-2-3/feed/ 0
En route vers la certification CKS (Certified Kubernetes Security Specialist) https://theexpert.squad.fr/theexpert/digital/devops/en-route-vers-la-certification-cks-certified-kubernetes-security-specialist/ https://theexpert.squad.fr/theexpert/digital/devops/en-route-vers-la-certification-cks-certified-kubernetes-security-specialist/#respond Mon, 05 Jul 2021 09:35:46 +0000 https://theexpert.squad.fr/theexpert/?p=16317 Par Mickaël D., Expert DevOps Au lieu d’un seul article global sur la préparation d’une certification, comme j’ai pu vous le proposer par le passé, je vais initier une série d’articles qui vous aideront à mieux comprendre les différents sujets sur lesquels vous serez interrogés (si vous souhaitez la passer).  Dans ce dossier, nous aborderons […]

L’article En route vers la certification CKS (Certified Kubernetes Security Specialist) est apparu en premier sur Blog TheExpert.

]]>
Par Mickaël D., Expert DevOps

Au lieu d’un seul article global sur la préparation d’une certification, comme j’ai pu vous le proposer par le passé, je vais initier une série d’articles qui vous aideront à mieux comprendre les différents sujets sur lesquels vous serez interrogés (si vous souhaitez la passer). 

Dans ce dossier, nous aborderons :

  1. Le Cluster Setup, 
  2. Le Cluster Hardening, 
  3. Le System Hardening, 
  4. Les Microservices Vulnerabilities, 
  5. Le Supply Chain Security, 
  6. Le Monitoring, Logging and Runtime Security. 

Network Security Policies

Ce premier article se focalisera sur le premier aspect, à savoir Cluster Setup, et traitera de plusieurs points tels que : 

  • Les Network Security Policies
  • CIS Benchmark afin de vérifier le niveau de sécurité de configuration de chaque composant de Kubernetes, 
  • La sécurisation des Ingress Controllers
  • La protection métadonnées des Nodes
  • L’usage de l’UI de Kubernetes et sa sécurisation, 
  • La vérification des binaires avant déploiement.

Que sont les Network Security Policies ? 

Il s’agit d’instructions destinées à spécifier comment un Pod peut communiquer avec des entités du réseau selon une combinaison d’identifiants : 

  • Les autres pods (à l’exception de lui-même), 
  • Les Namespaces avec lesquels il peut communiquer, 
  • Les blocs d’IP. Attention, dans ce cas, un Pod peut accéder à n’importe quel autre Pod situé sur le même Node

Lorsque l’on définit une Security Policy relative à un Pod ou à un Namespace, on fait appel à un Selector pour spécifier quel trafic est permis depuis ou vers le Pod/Namespace en rapport avec le selector

À SAVOIR : 

  • Par défaut, les Pods acceptent du trafic de n’importe quelle source. 
  • Les NetworkPolicies s’additionnent et n’entrent pas en conflit entre eux.
  • Un seul prérequis : un plugin Network ou CNI qui prends en charge les Network Policy !

Quelques exemples :

1. Limiter le trafic vers une application

yaml
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: api-allow
spec:
  podSelector:
    matchLabels:
      app: bookstore
      role: api
  ingress:
  - from:
      - podSelector:
          matchLabels:
            app: bookstore

2. Refuser le trafic vers l’extérieur du cluster Kubernetes

yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: foo-deny-external-egress
spec:
  podSelector:
    matchLabels:
      app: foo
  policyTypes:
  - Egress
  egress:
  - ports:
    - port: 53
      protocol: UDP
    - port: 53
      protocol: TCP
  - to:
    - namespaceSelector: {}

3. Refuser tout trafic non whitelisté vers un namespace

yaml
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: default-deny-all
  namespace: default
spec:
  podSelector: {}
  ingress: []

CIS Benchmarks

Le CIS (Center for Internet Security) est un consortium à but non lucratif mettant à disposition des guides et outils pour sécuriser les environnements informatiques. C’est un peu comme l’ANSSI en France.

Par défaut, un système peut être vulnérable à de nombreux types d’attaques et il est important de pouvoir le sécuriser un maximum. On parle d’hardening quand on sécurise la configuration et le fonctionnement d’un système.

Deux exemples :

  1. Dans le cas d’un serveur sur lequel des ports USB sont disponibles et que leurs utilisations n’ont pas été prévues, ceux-ci doivent être désactivés afin de prévenir tout types d’attaques par ce vecteur. 
  2. Quels utilisateurs ont accès au système et peuvent se connecter en tant que root ? Si ceux-ci effectuent des changements impactant le fonctionnement des services, il pourrait être impossible de connaître l’auteur des modifications. 

C’est pour cela que les best practices recommandent de désactiver le compte root et de se connecter avec son propre compte puis d’élever ses propres privilèges (à l’aide de sudo). 

Autres exemples, seuls les services et/ou filesystems utiles au fonctionnement du server devront être activés…Tout comme seuls les ports vraiment nécessaires doivent être ouverts et donc configurer le firewall de manière la plus fine possible. 

Le site CIS propose de nombreux benchmark et Framework d’hardening pour : 

  • Les Systèmes d’Exploitation Linux, Windows, OSX ainsi que mobile iOS et Android, 
  • Les plateformes Cloud AWS, Azure, Google
  • Les matériels réseau provenant de CheckPoint, Cisco, Juniper et Palo Alto
  • Ainsi que des middlewares tels que Tomcat, Docker ou encore Kubernetes.

CIS Benchmark appliqué à Kubernetes : kube-bench

Kube-bench est une application développée en GO, s’appuyant un maximum sur les recommandations de sécurité de CIS avec une configuration très évolutive grâce à l’utilisation de fichier en yaml et pouvant être utilisé de plusieurs manières différentes : 

  • En l’installation depuis un conteneur
  • En l’installation grâce au binaire téléchargé
  • En compilant les sources
  • En l’exécutant depuis un conteneur, que ce soit un conteneur isolé ou dans un cluster Kubernetes ou Openshift.

Kube-bench exécute les contrôles défini dans un fichier yaml nommé control.yaml et peut s’appliquer tout type de nodes de type master ou worker (peu importe la version).

id: 1.2
  text: Scheduler
  checks:
    - id: 1.2.1
      text: "Ensure that the --profiling argument is set to false (Scored)"
      audit: "ps -ef | grep kube-scheduler | grep -v grep"
      tests:
        bin_op: or
        test_items:
          - flag: "--profiling"
            set: true
          - flag: "--some-other-flag"
            set: false
      remediation: "Edit the /etc/kubernetes/config file on the master node and
        set the KUBE_ALLOW_PRIV parameter to '--allow-privileged=false'"
      scored: true

Une fois les tests effectués par kube-bench, les résultats sont enregistrés dans un fichier et chaque contrôle indique un état en fonction des quatre suivants : 

  • PASS, Le contrôle a été effectué avec succès. 
  • FAIL, le contrôle est un échec, mais la remédiation décrit comment corriger la configuration afin que, lors du prochain contrôle, celui soit OK. 
  • WARN, le test nécessite une attention particulière, vérifier la remédiation pour plus d’informations. Il ne s’agit pas forcément d’un rapport d’erreur. 
  • INFO

L’usage de l’UI de Kubernetes et sa sécurisation

Il s’agit ici de savoir comment installer le Dashboard de Kubernetes et de le sécuriser le mieux possible.  

Le Dashboard Kubernetes se déploie à l’aide de la commande suivante :

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.2.0/aio/deploy/recommended.yaml` et pour y accéder : `kubectl proxy --address 0.0.0.0.   

Il faut savoir que : 

  • Kubernetes supporte quatre modes d’authentification
  • Ceux-ci sont gérés par l’API de Kubernetes
  • Le Dashboard ne sert que de proxy et fait office de passe-plat vers Kubernetes pour toutes les informations relatives à l’authentification. 

Les attaques par le Front-end de Kubernetes sont nombreuses et ont été pendant longtemps le premier vecteur d’attaque.

L’authentification

Comme évoqué plus tôt, Kubernetes supporte quatre modes d’authentification parmi les suivants : 

  • Bearer Token, 
  • Username/Password, 
  • Kubeconfig,
  • Authorization Header (supporté depuis le version 1.6 et dispose de la priorité la plus élevée).

Les Bearer Tokens

Pour les configurer le plus efficacement possible, il est nécessaire d’être extrêmement familier avec les concepts de Service Account, Role, Cluster Role, et les permissions qui peuvent leur être attribuées.

ServiceAccount 

yaml
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin-user
  namespace: kubernetes-dashboard
EOF

ClusterRoleBinding

yaml
cat <<EOF | kubectl apply -f -
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: admin-user
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- kind: ServiceAccount
  name: admin-user
  namespace: kubernetes-dashboard

Une fois les deux objets précédemment créés, on peut obtenir le Bearer Token grâce à la commande suivante :
kubectl -n kubernetes-dashboard get secret $(kubectl -n kubernetes-dashboard get sa/admin-user -o jsonpath="{.secrets[0].name}") -o go-template="{{.data.token | base64decode}}"

Username/Password

Désactivé par défaut, car l’API de Kubernetes a besoin d’une configuration au niveau des attributs et non au niveau des rôles.

Kubeconfig

Avec ce mode d’authentification, seules les options spécifiées par le flag authentication-mode sont prise en charge dans le fichier sus-nommé. Dans le cas contraire, une erreur s’affiche dans le Dashboard.

Authorization Header

Pour ce type de méthode d’authentification, le Bearer Token sera nécessaire car vous en aurez besoin lors de chaque requête vers le Dashboard.

La vérification des binaires pré-installation

Il s’agit ni plus ni moins que de vérifier la valeur du hash des binaires relatifs à Kubernetes et de les comparer avec ceux que vous téléchargez sur votre serveur…au cas où votre action se ferait intercepter par un hacker. 

Même si le dit « hacker » modifie un fichier de l’archive, il faut savoir que toute modification d’une archive modifie également la valeur de son hash

Pour cela, une fois le téléchargement terminé, vous pouvez exécuter la commande suivante : shasum -a 512 kubernetes.tar.gz et comparer la valeur obtenue avec ce qui est affichée sur la page de téléchargement.

Par exemple, en téléchargeant :

kubeadm en version 1.21.0 dont la valeur de hash est 7bdaf0d58f0d286538376bc40b50d7e3ab60a3fe7a0709194f53f1605129550f

Je vais obtenir la même valeur de hash, une fois l’archive téléchargée (cette fois-ci avec la commande shasum -a 256 kubeadm

La sécurisation des Ingress Controllers

Tout d’abord : qu’est-ce qu’un Ingress Controller ? 

Il s’agit d’un objet Kubernetes qui gère l’accès externe aux services dans un cluster, généralement du trafic HTTP et peut également fournir des fonctionnalités de type équilibrage de charge. 

Les sujets traités dans cette partie seront : 

  • La création de certificats TLS
  • La création de secrets (intégrant les certificats TLS) dans Kubernetes,
  • La configuration d’Ingress Controllers intégrant les secrets.

Création d’un certificat TLS

Partant du principe que vous avez déjà créé votre Ingress Controller et qu’il est accessible en HTTP, la prochaine étape est de sécuriser son contenu à l’aide de HTTPS…et par conséquent de créer un certificat TLS auto-signé :

openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

Création du secret

Une fois la paire clé/certificat créé, et à moins d’avoir déjà déployé cert manager dans Kubernetes, il faut créer un secret afin de pouvoir intégrer, par la suite, le certificat TLS à l’Ingress controller :

kubectl create secret tls-secure-ingress --cert=cert.pem --key=key.pem

Configuration de l’Ingress Controller

Le certificat TLS et le secret créés, la dernière étape est d’intégrer le secret dans l’Ingress Controller.

yaml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: test-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
  - hosts:
      - test-secure-ingress.com
    secretName: tls-secure-ingress
  rules:
  - host: test-secure-ingress.com
    http:
      paths:
      - path: /service1
        pathType: Prefix
        backend:
          service: 
            name: service1
            port:
              number: 80
      - path: /service2
        pathType: Prefix
        backend:
          service: 
            name: service2
            port:
              number: 80

La protection meta-données des Nodes

Les Nodes Metadatas… De quoi s’agit-il ?

Toutes les machines virtuelles (nœuds) hébergées dans le Cloud devraient accéder au Endpoints des Nodes Metadata pour diverses raisons. Cependant, permettre l’accès à toutes les ressources n’est pas recommandé.

Pour améliorer la sécurité à ce niveau, il faut appliquer des Network Policies, de sorte que seules les ressources désignées au sein des Clusters Kubernetes pourraient avoir la capacité de contacter les Endpoints des Nodes Metadata

Toutes les informations dont vous pourriez avoir besoin sur le sujet se trouvent ici : 

Network Policies

Le principe des Network Policies est de gérer la communication Pod-to-Pod, Pod-to-Service et External-to-Service, de la même manière qu’un Firewall. L’identification des ressources impactées restant à la charge des administrateurs via des labels, des namespaces ou des adresses IP

La documentation officielle donne, par exemple, ceci : 

yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: test-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: db
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          project: myproject
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 6379
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 5978

Ici, ce qui nous intéresse, c’est principalement la possibilité de bloquer l’accès aux Metadata Endpoint à l’aide des Network Policies à un ou plusieurs Pods (cf. ci-dessous) : 

Deny trafic to metadata

yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: cloud-metadata-deny
  namespace: default
spec:
  podSelector: {}
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
          - <POD_IP_ADDRESS>

Allow trafic to metadata

yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: cloud-metadata-allow
  namespace: default
spec:
  podSelector:
    matchLabels:
      role: metadata-accessor
  policyTypes:
  - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 0.0.0.0/0
        except:
          - <POD_IP_ADDRESS>

Le prochain article traitera de toutes les problématiques relatives au cluster hardening, à savoir :

  • Les restrictions d’accès à l’API de Kubernetes, 
  • L’usage des Role Based Access Control dans le but de minimiser l’exposition, 
  • Le fine tuning des ServiceAccounts, 
  • La fréquence des mises à jour de Kubernetes.

L’article En route vers la certification CKS (Certified Kubernetes Security Specialist) est apparu en premier sur Blog TheExpert.

]]>
https://theexpert.squad.fr/theexpert/digital/devops/en-route-vers-la-certification-cks-certified-kubernetes-security-specialist/feed/ 0
Introduction to Machine learning (1/3) https://theexpert.squad.fr/theexpert/digital/devops/introduction-to-machine-learning-1-3/ https://theexpert.squad.fr/theexpert/digital/devops/introduction-to-machine-learning-1-3/#respond Tue, 29 Jun 2021 08:07:37 +0000 https://theexpert.squad.fr/theexpert/?p=16274 Wrote by Wassim B., Cybersecurity Expert SQUAD Nowadays, network Functions Virtualization (NFV) [1] and Cloud-native Network Functions (CNFs) offer new ways of designing, scaling and operating networks, as customer-centric services can be elastically scaled and easily orchestrated, not only at the core but also at the edge of the network. In particular, the gradual shift […]

L’article Introduction to Machine learning (1/3) est apparu en premier sur Blog TheExpert.

]]>
Wrote by Wassim B., Cybersecurity Expert SQUAD

Nowadays, network Functions Virtualization (NFV) [1] and Cloud-native Network Functions (CNFs) offer new ways of designing, scaling and operating networks, as customer-centric services can be elastically scaled and easily orchestrated, not only at the core but also at the edge of the network.

In particular, the gradual shift from legacy physical network functions to Virtualized Network Functions (VNFs) running on VMs and Cloud-native Network Functions (CNFs) running as containerized microservices promises a wider choice of deployment environments (private or public cloud infrastructure) and more efficient use of computing resources (data center or multi-access edge computing). 

In the midst of the recent softwarisation of networks, existing security solutions remain ill-equipped [[2]] to deal with threats and misbehaviors, making virtualized networks highly vulnerable. While certain preventive technologies [[3]] have been designed to prevent malicious/unexpected activities from threatening networked systems from a hardware and software perspective, it becomes vital to monitor and analyze the events occurring in today’s networks to look for potential signs of faults or security breaches. 

To this end, we introduce an anomaly detector that establishes the normal behavior of the networking system to identify any anomaly as a deviation between the given observations and the pre-set behavior. For this purpose, our anomaly monitors some key indicators that reflect the state and behavior of NFV/CNF environment.

While the vast majority of anomaly detectors are based on machine learning techniques [[4]], we leverage a statistical model called autoregressive integrated moving average (ARIMA) and its variants [[5]] to model and predict the behavior of the virtualized networking system.

The advantage is threefold. Instead, deep learning methods, e.g. Recurrent Neural Networks (RNNs) [1] and Long Short-Term Memory (LSTM) [[6]] involve a heavy training, tuning and optimizing of the many network parameters.

As mentioned, ARIMA and its variants require little training and thereby the availability of small-size datasets. In particular, ARIMA establishes and forecasts the behavior of the virtualized environment based on auto regression with some parameters fitted to the model; then it applies a moving average with a set of parameters.

Second, anomaly detection is resource consuming because it entails analyzing the behavior of an NFV/VNF as a whole, on the basis of multiple indicators (such as CPU load, network memory usage, packet loss, traffic load collected as time series to name a few). In order to support the lightweight monitoring of multiple indicators, we leverage a variant of ARIMA called Vector Autoregressive Integrated Moving Average (VARMA), which deals with multivariate time series. Following, we complement our anomaly detector with a Security Information and Event Management (SIEM) system [5] that orchestrates the collection, correlation, and analysis of real-time events across heterogeneous sources and is used to alert network administrators and react by e.g., rerouting traffic through an alternative link.

In order to evaluate the performances associated with our anomaly detector, we further set up a testbed in which a virtualized IP Multimedia Service (vIMS) [[7],[8]] running on Kubernetes containers supports voice and video calls with high sound quality and minimal delay.  


  • [1] Donovan, J., & Prabhu, K. (Eds.). (2017). Building the network of the future: Getting smarter, faster, and more flexible with a software centric approach. CRC Press.
  • [2] NFV White Paper, (2012), Network Functions Virtualisation–Introductory White
  • [3] Box, G. E., Jenkins, G. M., Reinsel, G. C., & Ljung, G. M. (2015). Time series analysis: forecasting and control. John Wiley & Sons.
  • [4] Agrawal, S., & Agrawal, J. (2015). Survey on anomaly detection using data mining techniques. Procedia Computer Science, 60, 708-713.
  • Chalapathy, R., & Chawla, S. (2019). Deep learning for anomaly detection: A survey. arXiv preprint arXiv:1901.03407.
  • [5] Brockwell, P. J., Brockwell, P. J., Davis, R. A., & Davis, R. A. (2016). Introduction to time series and forecasting. springer.
  • [6] Roh, Y., Heo, G., & Whang, S. E. (2019). A survey on data collection for machine learning: a big data-ai integration perspective. IEEE Transactions on Knowledge and Data Engineering.
  • [7] Openimscore
  • [8] What is Kubernetes ?

L’article Introduction to Machine learning (1/3) est apparu en premier sur Blog TheExpert.

]]>
https://theexpert.squad.fr/theexpert/digital/devops/introduction-to-machine-learning-1-3/feed/ 0
AWS S3M Pattern: 5 Steps to tie Serverless & Microservice Securely https://theexpert.squad.fr/theexpert/cloud/aws-s3m-pattern-5-steps-to-marry-serverless-microservice-securely/ https://theexpert.squad.fr/theexpert/cloud/aws-s3m-pattern-5-steps-to-marry-serverless-microservice-securely/#respond Thu, 24 Jun 2021 09:43:25 +0000 https://theexpert.squad.fr/theexpert/?p=16222 Wrote by Naoufal E., Cloud Expert Making serverless architectures tied to microservices architectures on the AWS Cloud is a fun job, and it allows us to learn new things every day ! But mostly, we need Abstract Patterns that already exist to implement and adapt them according to our use case to avoid spending a […]

L’article AWS S3M Pattern: 5 Steps to tie Serverless & Microservice Securely est apparu en premier sur Blog TheExpert.

]]>
Wrote by Naoufal E., Cloud Expert

Making serverless architectures tied to microservices architectures on the AWS Cloud is a fun job, and it allows us to learn new things every day !

But mostly, we need Abstract Patterns that already exist to implement and adapt them according to our use case to avoid spending a lot of time designing something that already exists.

My goal here is to introduce you to one of my favorite Patterns that securely tie serverless and micro-services architecture.

This Pattern will help you to save lots of time when designing and thinking about a project that requires authentication to access one or more microservices deployed in a private network.

It is Strong, Secure, Serverless, and Micro, So I named it S3M, and I’m going to make it as Abstract as possible, and implement it with a concrete example of my favorite trending technologies, so you’ll have the choice to implement it your way 💪.

The Use Case

Assuming that we are invited to develop an application that consists of a Front-end that communicates with many microservices backends that are deployed on containers managed by ECS/Fargate (or EKS) and protected in a private network.

All those microservices will use the same logic of authentication / authorization. For example: blocking all non-authenticated calls, verifying the JWT token, and requesting roles from a DynamoDB table to manage permission.

A custom Authorizer as a solution is the best choice to centralize all auth logic rather than developing each logical authentication/authorization for each micro-service, but how? 👌

To access those micro-services, we need to implement the API Gateway private integration: all requests will be verified by the authorizer of the API Gateway and passed through an NLB in a private network by a VPC Links that routes incoming requests (API calls) to the targeted resource (Containers). Take a look at the architecture below.

Project Architecture

To understand S3M Abstract Pattern with a concrete example, we’ll follow this architecture :

Global Architecture for S3M Pattern
S3M: Architecture

Resume: We have a front that communicates with a backend having as entry point an API Gateway that includes Authorizer In Front of private NLB that routes incoming requests to the targeted resource (Containers)

So, as you can see, the S3M Pattern consists of a(n):

  • Authentication Provider to generate a JWT Token (I’ll make it simple 😊, so I’ll generate one here)
  • Front-end framework (Angular in my case)
  • Backend-end API (.Net Core in my case)
  • Private and Public Subnets
  • Container Manager and Containers for backend deployment (ECS/Fargate in my case)
  • Registry for docker image (ECR in my case)
  • NLB (Network Load Balancer)
  • VPC Links
  • API Gateway
  • Lambda Authorizer (NodeJs in my case)

Take a deep breath and analyze the architecture to fully understand it, and if all seems good, it’s time to get our hands dirty 😊


Prerequisite:

→ AWS Account

→ AWS Programatically Acount with Programmatic access and Admin Permission

→ Basic knowledge of the backend and frontend technos besides an initiation in the AWS cloud will be better to completely understand


Here below, I will show you the implementation by using AWS Console.

Steps for Technical Implementation

Step 1: let’s create our Angular Front-End :

Prerequisite:

→ Install Angular Globally in your machine, open a terminal and type

npm install -g @angular/cli
  • Clone the Angular project example from my GitHub Repo or you can follow the steps bellow
  • Generate your JWT Token here and replace it at the app.component.ts
import { Component } from '@angular/core';
import { HttpClient, HttpParams } from '@angular/common/http';
import { environment } from 'src/environments/environment';
import { Observable } from 'rxjs';
const token =
  'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkVMIEdBRkEgTkFPVUZBTCIsImFkbWluIjp0cnVlLCJqdGkiOiIxOGI2ZTdjMS00NzJiLTQ5NDctYTAyYS1hZmU5YzA3ZjdmNmQiLCJpYXQiOjE2MDg3NTE2NTEsImV4cCI6MTYwODc1NjEzOX0.Kx9s5ozJl9tN87yYHKDyVNja3mK3t4FN_PrGYHaXavQ';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss'],
})
export class AppComponent {
  title = 's3a-example';
  items: Observable<any[]>;
  /**
   *
   */
  constructor(private httpclient: HttpClient) {}

  // The best practice is to define a service that call backend api
  // And to make an interceptor that add the generated token to the request header
  // But for saving time, in this tuto i will make him here because is not a tuto about Angular
  getAll() {
    // Generate token example
    console.log('token');
    this.items = this.httpclient
      .get<any[]>(`${environment.baseURL}WeatherForecast`, {
        headers: { Authorization: `Bearer ${token}` },
      })
      .pipe();
  }
}

Step 2: let’s create our backend with .net core :

Prerequisite:

→ Install Visual Studio 2019 or VSCode with .netcore

  • Clone the .net core project from my GitHub Repo
  • You will find this example controller (WeatherForecastController with GET method): it sufficient for our test
S3A Backen Step
Controller Example

I already enabled cors, then we can access the backend from any origin globally.

app.UseCors("AllowOrigin");
services.AddCors(c =>
  {
  c.AddPolicy("AllowOrigin", 
    options => AllowAnyOrigin().AllowAnyHeader().AllowAnyMethod());
  });

Step 3: let’s make a local test :

  • Start your Backend by clicking on the play button of your Visual Studio and copy-paste the localhost port of your backend in the dev environment variable (environement.ts) of your Angular front (in my case the backend port is 49159)
export const environment = {
  production: false,
  baseURL: 'http://localhost:49159/', // replace it by the url of your backend
};

Start your angular project → in the route folder of your cloned front-end, open a terminal, and type:

npm i // to install all dependency
ng serve
  • The interest of this test is to see if the back and the front communicate without any problem locally, as well as to be sure that the JWT Token has been passed in the header of the request.
Local Test of Testing Decoupled Web Application
Local Test of Testing Decoupled Web Application

Step 4: prepare our AWS infrastructure

1. Create a container in ECR (Elastic Container Repository):

Amazon Elastic Container Registry (ECR) is a fully managed container registry that makes it easy to store, manage, share, and deploy your container images and artifacts anywhere.

  • Open the ECR Dashboard
  • Click on “Create Repository”
  • Name your repo and click “Create Repository”, that’s it! 😜
Create a Repository into Elastic Container Registry for docker images
Elastic Container Registry

2. Create an ECS Cluster (Elastic Container Service):

Amazon ECS makes it easy to deploy, manage, and scale Docker containers running applications, services, and batch processes. Amazon ECS places containers across your cluster based on your resource needs and is integrated with familiar features like Elastic Load Balancing, EC2 security groups, EBS volumes, and IAM roles.

  • After creating the repo you will stay on the same page in which you can create also a cluster or you can go here
  • Click on the Clusters at the left menu and click on “Create Cluster
  • Select the template Networking Only and click “next step”
ECS Cluster Template
ECS Cluster
  • Name your container and check the “Create VPC” option, choose 3 subnets and click “Create” and wait.
Create an Elastic Container Cluster with Network Template
Cluster Networking Template
  • y default, the created subnets are public so, in the next step, we will make two of them privates and create a NatGateway in the public one to allow private resourceslike ECS Tasks to pull docker images from the registry.

3. Configure VPC :

A VPC is an isolated portion of the AWS cloud populated by AWS objects, in the step before we create one with 3 public Subnet

Let’s make 2 of them private and leave one Public (for example the 10.0.2.0/24 will stay public)

  • Go to VPC Dashboard and create a new NatGateway and as a subnet choose the one that you’ll let it public (I choose 10.0.2.0/24 )
  • ⚠ to know the IP of the subnet go to the subnets table

Go now to the “Route Table”, you will notice 2 new ones are created, one private and one public, and the public one has the three created subnet.

Route Table

Select the private route table → in the route tab click on “edit route” and add a route to the Nat Gateway created.

0.0.0.0/0 => NatGateway
Add Route 0.0.0.0/0 targeting NAT Gateway
  • Now associate the remaining subnets (2 Subnets) to this route table (private) and change their names (replace /public by /private) → In the “Subnet Associations” tab click on “Edit Subnet Association” and select the subnets to associate (10.0.0.0/24 and 10.0.1.0/24).

Done for the container and the subnets, we will back again to create services and tasks … don’t worry ! These steps is for preparing infrastructures 

4. Create an NLB :

Elastic Load Balancing automatically distributes your incoming traffic across multiple targets, such as EC2 instances, containers, and IP addresses, in one or more Availability Zones.

Network Load Balancer functions at the fourth layer of the Open Systems Interconnection (OSI) model. It can handle millions of requests per second. After the load balancer receives a connection request, it selects a target from the target group for the default rule. It attempts to open a TCP connection to the selected target on the port specified in the listener configuration.

  • Go to EC2 console in the left menu scroll down, click on “Load Balancers” then on “Create Load Balancer” then choose “Network Load Balancer” and click “Create”
Load Balancers Types

Name your NLB, The schememust be “internal” and for VPC. So, you should select the “created one (Step 4.3) ” and check all its private subnets.

  • Click “Next: Configure Security Settings” then “Next: Configure Routing”
  • For Target Type choose IP → for Protocol choose “TCP” → then “Next: Register targets” then “Next: Review” and “Create”
  • Copy the DNS Name of the created NLB, we’ll need it for the VPC Links
Get the DNS of Network Load Balancer
NLB DNS

Don’t worry, we will register our target after creating our cluster’s service 😜

. Create the VPC Link :

VPC link is encapsulated by an API Gateway resource of VpcLink. It is responsible for forwarding API method requests to the VPC resources and returns backend responses to the caller. For an API developer, a VPCLink is functionally equivalent to an integration endpoint.

  • Go to the API Gateway dashboard, in the left menu click “VPC Links”, then click “Create” and choose “VPC Link for REST APIs”
  • Name it, and for “Target NLB”, you know what to do 😝 (select the NLB created in the step before(Step 4.4) and click “Create”
Create a VPC Link
VPC Link

⚠ The VPC Link takes a few minutes for creation, so is recommended to wait for its creation before going to the next step.

6. Create the ApiGateway and connect it to the NLB:

API Gateway API with private integration provides our customers access to HTTP/HTTPS resources within your Amazon Virtual Private Cloud (Amazon VPC). Such VPC resources are HTTP/HTTPS endpoints on an EC2 instance behind a Network Load Balancer in the VPC. The Network Load Balancer encapsulates the VPC resource and routes incoming requests to the targeted resource.

  • Go to the API gateway Dashboard and click “Create API”, choose the “REST API” Template and click “Build”.
  • Select “New API” then name it and click “Create API”
  • Click “Action/Create Resource then configure as explained in the image below and click “Create Resources”
Create API Gateway Resource as proxy
API Gateway Resource
  • By default the method “Any” is created in this resource and we should just configure it by selecting the “VPC link” and copy-paste the generated “DNS of the NLB” that we have created before (Step 4.4) concatenated by “/{proxy}” at the endin the endpoint URL as explained in the image below, then click “save”.
  • For example, if your DNS is: s3m-nlb-private-b144930068ace954.elb.us-east-1.amazonaws.com in the endpoint URL should be: http://s3m-nlb-private-b144930068ace954.elb.us-east-1.amazonaws.com/{proxy}
Api Gateway Proxy mode with NLB and VPC Link
Setup Proxy for ApiGateway

So, as you can see, we created our Container Manager (ECS Cluster), our container registry (ECR), and also our NLB connected with API Gateway via the VPC Link.

Almost done, you can take a 15 min break ✌. The next step will be to connect the Lambda Authorize with the API Gateway.

7. Create the Lambda Authoriser:

Lambda authorizer (formerly known as a custom authorizer) is an API Gateway feature that uses a Lambda function to control access to your API.

A Lambda authorizer is useful if you want to implement a custom authorization scheme that uses a bearer token authentication strategy such as OAuth or SAML, or that uses request parameters to determine the caller’s identity.

  • Go to Lambda dashboard and click on “Create Function”, Select “Author From Scratch”, name it, leave the runtime at node.js 12.x, then click “Create Function”
Create a Lambda Function
  • You can download the lambda zip from my Github Repo
  • Scroll down to Function code, on the right side click on “Actions” and upload “Upload a .zip file”, then upload the downloaded zip and click “save” (I made this zip for you to avoid creating “layers” etc …)
Upload a zip to an  AWS Lambda
Upload Lambda as a ZIp

This gist is inspired by AWS Labs

8. Attach the Authoriser to the API Gateway:

  • Go to ApiGateway Dashboard (always verify your region) and select the API that you created before (Step 4.5), in the left menu scroll down to the Authorizers and click on “Create new Authorizer” → name it → at the Lambda Function select the one we have created before (Step 4.7), for “Lambda Event” check “Token” and copy-paste “Authorization” in Token Source, then click on “Create” and “Grant & Create”
Attach Lambda Authorizer to Api Gateway Authorizer, #Authorizer
  • Now attach the Authorizer to the resources → Select “Resources” in the left menu → select “Any” method and click on “Method Request” → then attach the created Authorizer (if the authorizer doesn’t appear refresh the page)
  • Now let deploy our API Gateway (choose a new stage and create one) and copy-paste the API Endpoint into the Angular project Prod environment variable (environment.prod.ts) that you have cloned before (Step 3.1). !!! (make sure to have “/” at the end of the endpoint)
Deploy th Api Gateway and Copy-paste the endpoint into the Front
Deploy the API Gateway and Copy-paste the endpoint into the Front

→ Next Step we’ll prepare S3 Bucket for hosting our front

9. Create S3 Bucket for Static Web Site Hosting:

You can use Amazon S3 to host a static website. On a static website, individual webpages include static content. They might also contain client-side scripts.

  • Go to S3 Dashboard and click on “Create bucket”, name it, uncheck “Block all public access” then check “I Acknowledge….”, then click “Create Bucket”
  • Now enable “Static Web Site Hosting”, to do so → select the created Bucket → to go to “Properties” → Scroll down to the bottom, at Static website hosting click on “Edit” → then enable it as shown in the image below → then click “Save changes”

Our Infrastructure is Ready now, let deploy our front, back, create task and services and bring all pieces together 💪

Step 5: Bring All Pieces together (Deployment):

Let host our Angular Front-end :

  • In the route directory of the Angular Project, open a terminal and type
ng build --prod
  • It will generate a new folder called “dist”
  • Open the S3 Dashboard → select the bucket that we created before (Step 4.9) and click on “Upload” → then go to the generated “dist” folder and drag and drop all its contents to this Bucket.
  • All the contents should be reachable by everyone, take a look at the GIF below
  • Check the link of your hosted application (properties of the bucket scroll down to Static Web Hosting)
Host Angular Front in S3 Bucket for hosting static website
Deploy Angular Front to S3

Let’s deploy our backend as a Docker image :

Prerequisite:

→ Install the latest version of the AWS CLI

  • Go to ECR Dashboard (always verify region) and select the repository that we created before (Step 4.1)
  • Click on “View Push Command” to see the command that should be used to push the docker image
  • Go to the “route folder” of your backend solution and open a terminal
  • Follow the “View push Command” window, then replace the second command with this one
docker build -t s3m-test -f .\S3MExampleBackend\Dockerfile .
Build .net docker image and push it to ECR
Deploy Backend
  • Copy the URI of the pushed image

Let’s create a Task Definition

Task definitions specify the container information for your application, such as how many containers are part of your task, what resources they will use, how they are linked together, and which host ports they will use.

  • Go to ECS Dashboard, in the left menu select “Task Definitions” then click on “Create New Task Definition”
  • Select Launch Type as Fargate
  • Name your task → scroll down to Task Execution Role, if you haven’t yet a role select “create one” it will be created automatically.
  • Add your container (name it → past the URI of pushed image → For memory Limits take 128, and for port-mapping take 80
Task Definition

Let Create a Service :

A service lets you specify how many copies of your task definition to run and maintain in a cluster. We will use it with a Network Load Balancer to distribute incoming traffic to containers in our service.

  • Go to the ECS Dashboard → in the left menu select “Clusters” then select the Cluster that we created before (Step 4.2)
  • In the “Service tab” click on “Create”
  • For Launch Type select “Fargate” → for Task Definition select “the one created before (Step 5.3) ” → give it a name and a number of tasks → then click “Next Step”
  • For the VPC choose the “created VPC” (Step 4.3) and select its private network
  • For Load Balancer select the “One Created Before” (Step 4.4) and for production listener, select TCP:80 → then click on “next step” then “Create Service” → then “view Service” and wait for task Status to become “RUNNING”
Create an ECS Service
ECS Service

All pieces now are together let test our application

Test the Applications

Yeeeeeeees everything work like a magic 😜

That means, all pieces are well connected and we respect every step of the infrastructure as well as deployment to make our project works.

Also, in the Authorizer code, we tell it that only admin can make a call, and in the generated token if you remember admin is set to true

JWT

Let reverse the if’s condition of the Lambda Authorizer and see what happen, so if the user is not admin he can do a call otherwise no

  • Go to Lambda Dashboard → Select the one created before (Step 4.7) → scroll down to the code and replace
if(decodedJwt.admin) by if(!decodedJwt.admin)
  • Then Deploy the function → you will see that you are not authorized to make this call

Conclusion

My goal here is to make it easy for everyone to implement the S3M Pattern.

L’article AWS S3M Pattern: 5 Steps to tie Serverless & Microservice Securely est apparu en premier sur Blog TheExpert.

]]>
https://theexpert.squad.fr/theexpert/cloud/aws-s3m-pattern-5-steps-to-marry-serverless-microservice-securely/feed/ 0
Réduire les vulnérabilités de votre code avec CodeQL https://theexpert.squad.fr/theexpert/digital/devops/reduire-les-vulnerabilites-de-votre-code-avec-codeql/ https://theexpert.squad.fr/theexpert/digital/devops/reduire-les-vulnerabilites-de-votre-code-avec-codeql/#respond Tue, 15 Jun 2021 07:52:24 +0000 https://theexpert.squad.fr/theexpert/?p=16176 Par Michael V. , Expert en CyberSécurité CodeQL est un outil permettant de découvrir des vulnérabilités en analysant le code source de vos applications. Il peut aussi bien être utilisé pour des tests automatisés durant le Software développement Life Cycle (SDLC), que par des chercheurs en sécurité pour des projets spécifiques. Un de ses cas […]

L’article Réduire les vulnérabilités de votre code avec CodeQL est apparu en premier sur Blog TheExpert.

]]>
Par Michael V. , Expert en CyberSécurité

CodeQL est un outil permettant de découvrir des vulnérabilités en analysant le code source de vos applications.

Il peut aussi bien être utilisé pour des tests automatisés durant le Software développement Life Cycle (SDLC), que par des chercheurs en sécurité pour des projets spécifiques.

Un de ses cas d’usage les plus rependus est probablement le scan automatique de projet GitHub, dont on peut bénéficier gratuitement [1].

L’outil se distingue par ces « queries » au format « from-where-select » qu’il est possible d’exécuter directement en ligne [2].

Figure 1: Intégration Github

Il est également possible de s’approprier l’outil afin de rechercher des vulnérabilités dans le code hébergé ou rapatrié localement sur une machine dédiée. C’est à ce moment-là qu’intervient CodeQL-CLI.

Cet outil est déjà très bien documenté [3]. L’idée de cet article est d’aller à l’essentiel afin de dégrossir rapidement la recherche de vulnérabilités dans une application cible, en vue de mener ensuite des tests plus spécifiques.

Pour cela, il est nécessaire de télécharger l’outillage afin de l’utiliser localement, à savoir :

  • Les binaires permettant d’exécuter nos requêtes (queries) [4] ;
  • Les queries elles-mêmes [4], qui serviront de base pour débuter la recherche de vulnérabilités.

Ces deux éléments sont ensuite placés côte à côte dans un même répertoire. Ceux-ci portant le même nom, un des deux doit être renommé. Dans notre cas le dossier contenant nos queries s’appelle « codeql-queries ». Notons que CodeQL peut être ajouté au Path, bien que cela ne soit pas indispensable :

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
da---l        06/06/2021     10:52                codeql
da---l        06/06/2021     10:48                codeql-queries

Notre code et ses dépendances doivent également être convertis en une base de données que CodeQL pourra ensuite analyser.

Pour cela la commande database create va tenter de retrouver automatiquement, ou prendre en entrée, les options de compilation du projet et créer une base de données qu’il sera ensuite possible de maintenir dans le temps.

Ci-dessous un exemple de commande exécutée depuis le répertoire courant d’un projet, dans ce cas précis l’outil retrouve automatiquement le pom.xml du projet spring et la commande maven adéquate.

Evidement ce ne sera pas toujours le cas et l’option --command permet de corriger les éventuels écarts ou d’utiliser un outil spécifique pour la compilation :

..\codeql-home\codeql\codeql.cmd database create ..\java-spring-POC1 --language=java

À l’issue de la compilation, l’outil confirme que la base de données a été correctement créée par le retour suivant :

Successfully created database at <PATH>

L’objectif initial étant de dégrossir la recherche de vulnérabilités, il est préférable de lancer tout une batterie de requêtes. D’un point de vue sécurité, les queries préexistante classées par CWE (Common Weakness Enumeration) constituent un bon point de départ.

Pour aller à l’essentiel, des répertoires nommés « codeql-suites » contiennent des listes de requêtes spécifiées dans des fichiers .qls. Notons que l’extension .ql contiendra la requête CodeQL qui sera individuellement analysée.

Enfin, la commande database analyze et les options suivantes permettent de spécifier le chemin des « helpers » nécessaires à notre listes de requêtes ainsi que le format souhaité du résultat de l’analyse :

 .\codeql-home\codeql\codeql.cmd database analyze java-spring-POC1-database .\codeql-home\codeql-queries\codeql-main\java\ql\src\codeql-suites\java-lgtm.qls --format=sarifv2.1.0 --output=OUTPUT.sarif --search-path .\codeql-home\codeql-queries\codeql-main\misc\suite-helpers

Différents formats sont possibles pour les résultats, en voici un extrait au format JSON avec notre fichier et la ligne comportant une vulnérabilité de type injection SQL :

    "results" : [ {
      "ruleId" : "java/sql-injection",
      "ruleIndex" : 54,
<…SNIP…>
            "uri" : "src/main/java/com/appli/test/testsqli.java",
            "uriBaseId" : "%SRCROOT%",
<…SNIP…>
          "region" : {
            "startLine" : 18,
            "startColumn" : 44,
            "endColumn" : 45
          }

Une fois cette première étape effectuée, la recherche de vulnérabilité peut être poursuivie par des requêtes CodeQL plus spécifiques, une lecture manuelle du code ou encore des tests dynamiques.

L’article Réduire les vulnérabilités de votre code avec CodeQL est apparu en premier sur Blog TheExpert.

]]>
https://theexpert.squad.fr/theexpert/digital/devops/reduire-les-vulnerabilites-de-votre-code-avec-codeql/feed/ 0
PlugIn Kubernetes, CloudRun… Ce qu’il fallait retenir du Paris Containers Day ! https://theexpert.squad.fr/theexpert/digital/devops/plugin-kubernetes-cloudrun-ce-quil-fallait-retenir-du-paris-containers-day/ https://theexpert.squad.fr/theexpert/digital/devops/plugin-kubernetes-cloudrun-ce-quil-fallait-retenir-du-paris-containers-day/#respond Thu, 10 Jun 2021 08:38:50 +0000 https://theexpert.squad.fr/theexpert/?p=16146 Par Mickaël D., expert DevOps Le Paris Containers Day est un événement organisé par Wescale et Publicis Sapient (Anciennement Xebia) depuis 2016 et orienté Conteneurs et Orchestration. L’événement a finalement eu lieu en ligne, à l’instar d’autres conférences telle que l’AWS Re:Invent, malgré bien qu’il ait lieu à l’origine en physique. De plus, contrairement aux […]

L’article PlugIn Kubernetes, CloudRun… Ce qu’il fallait retenir du Paris Containers Day ! est apparu en premier sur Blog TheExpert.

]]>
Par Mickaël D., expert DevOps

Le Paris Containers Day est un événement organisé par Wescale et Publicis Sapient (Anciennement Xebia) depuis 2016 et orienté Conteneurs et Orchestration. L’événement a finalement eu lieu en ligne, à l’instar d’autres conférences telle que l’AWS Re:Invent, malgré bien qu’il ait lieu à l’origine en physique.

De plus, contrairement aux précédentes éditions qui se déroulaient sur une seule journée, celle-ci prend place sur deux après-midis.

Que retenir de cet ensemble de conférences ? 

Peu d’annonces, ce n’est vraiment pas le but recherché par Wescale/Publicis Sapient et par les différents intervenants. Cependant, de nombreux retours d’expériences sur des « subjets » tels que les runtimes de conteneurs, la sécurité appliquée à Kubernetes, Cloud Run ou le développement de plugins pour Kubernetes .

1. Détection et Réaction aux menaces dans Kubernetes avec Falco

Présentée par Thomas Labarussias, Site Reliability Engineer chez Qonto, Contributeur pour Falco et créateur de FalcoSidekick

Cette session a pour but d’expliquer le fonctionnement de Falco, un projet relatif à la sécurité des runtimes et détecteur de menaces au sein de Kubernetes, et de présenter également FalcoSidekick ainsi que son fonctionnement. 

Falco est un agent de détection des comportements *exotiques* au runtime créé par Sysdig, il capture en temps réel les journaux, aussi bien ceux du kernel, des conteneurs ou du Kubernetes. 

À l’aide d’un moteur de règles relativement simple (il s’agit d’instruction au format YAML) et paramétrable, Falco déclenche des alertes en fonction du contenu des journaux capturés. De plus, il est livré avec plus d’une centaine de règles prédéfinies. 

L’architecture par défaut de Falco ne prévoyant que cinq types de sorties différentes (stdout, file, gRPC, shell et HTTP), FalcoSidekick permet d’étendre tout cela en ajoutant également une interface utilisateur.

N’hésitez pas à faire un tour sur le site officiel.

2. CloudRun: un produit managé de Google Cloud compatible Knative

Présentée par Guillaume Blaquière, Cloud Architect chez Sfeir. 

CloudRun est une solution Serverless pour l’hébergement de conteneurs contrairement à Cloud Functions ou à App Engine qui sont plutôt orientés code source, ce qui permet une portabilité plus importante. 

Parmi les fonctionnalités de CloudRun, on retrouve une scalabilité automatique s’appuyant sur le nombre de requêtes que le conteneur doit traiter, ainsi qu’un mode managé basé sur Knative et la possibilité de bénéficier de la puissance de Anthos sur les clusters Cloudrun. 

Il présente également des démonstrations de Knative sur AWS/EKS, GCP/GKE, sur GCP/HKE + le plugin CloudRun et, finalement, un CloudRun Managé.

Plus d’infos sur

3. Et pour quelques runtimes de plus…

Présentée par Thomas Gérardin – Cloud Builder chez Wescale

Cette intervention commence par un historique de la conteneurisation : depuis 1979, avec Chroot, jusqu’à maintenant avec les différents runtimes ainsi que l’émergence d’un standard (Container Runtime Interface – CRI) proposé par l’OCI (Open Container Initiative).

Voici un listing et quelques informations sur différents runtimes : 

  • **Docker** qui s’appuie sur le runtime **containerd**, 
  • **containerd** qui lui-même s’appuie sur **runc**, 
  • **runc** ou **crun** qui sont des runtimes de bas niveau (proche du kernel et respectivement écrit en Go et en C), 
  • **rkt** (dont le projet a été arrêté en février 2020), 
  • **cri-o** qui gère de nombreuses fonctionnalités, dont les images, la sécurité, les métriques, le système de fichiers, etc… 
  • **Kata-container** qui s’engage vers une nouvelle voie, celle des micro-VM (qui met l’accent sur une isolation plus profonde). 

Il nous rappelle que les runtimes apportent différentes fonctionnalités selon leur niveau et leur “proximité” avec le kernel, décrit un exemple de stack avec un orchestrateur de conteneur lié à un ou plusieurs runtimes de conteneur (en fonction des fonctionnalités recherchées).

Plus d’infos sur :

4.    Les conteneurs détournés

Présenté par Emmanuel Pluot et Olivier Cloirec, Site Reliability Engineer chez Publicis Sapient.

Cette conférence aborde des sujets assez variés tels que : 

Builder : focus sur le langage C++ et la compilation lors du *build* de l’image du conteneur. 

Interpreteur : retour d’expérience avec le langage Groovy lors du *build* du conteneur. Le principe est assez identique, un exécutable est généré dans le but de tester un cas pratique, 

nsenter : hacker la machine hôte en volant les namespace d’un processus hôte grâce au PID d’un processus. Cela ressemble à une faille de sécurité et peut être mitigée via un contrôleur d’admission, 

LogForwarder : comment rediriger les logs vers la sortie **stdout** à l’aide de **Fluentbit**, 

X11 / IDE : Détourner et démarrer une application graphique dans un conteneur.

La présentation fait la part belle à Visual Studio Code, mais au vu des packages installés, n’importe quelle application graphique peut être installable. Cette application des fonctionnalités relatives aux conteneurs fait partie des moins connues et des moins utiles.

5.    Créer et distribuer un plugin pour Kubernetes

Présenté Par Aurélie Vache – Cloud Developper chez StackLabs – et Gaëlle Acas – Site Reliability engineer chez Stack Labs.

Aurelie Vache, déjà très connue pour son travail de vulgarisation sur Kubernetes et l’écosystème des conteneurs en général, a commencé par expliquer le principe de **kubectl** et son fonctionnement *ultra simple. En revanche, l’ajout de plugins étant lié au core de **Kubernetes **, la *release* peut avoir un cycle relativement long.

Cependant, la partie la plus longue de l’intervention est liée à la création de plugin qui se décompose en : 

  • Tout d’abord créer un fichier nommé *kubectl-myplugin*, 
  • Le rendre exécutable, 
  • Le placer dans le **PATH** (/usr/local/bin, par exemple), 
  • Exécuter le plugin. 

Le tout avec des langages relativement simple à utiliser tels que Python, Bash, Go, Rust ou Quarkus (Ceux avec lesquels, nous pouvons coder un CLI)

Une fois le plugin développé et testé, il reste le packaging et c’est à ce moment que Krew, le package manager de plugins à destination Kubernetes, entre en scène.

Plus d’infos sur Krew

6. Des conteneurs dans des conteneurs (maritime)

Présentée par Guilhem Lettron, Site Relibaility Engineer Freelance, et Barthelemy Vessemont, Head of Infrastructure, chez Storelift.

Le but de la présentation étant de créer un magasin autonome sans caisse grâce à des conteneurs maritimes en gérant l’hétérogénéité de plusieurs détails tels que le matériel (Raspberry, Arduino, GPU pour le Machine Learning) et de logiciels conteneurisés.

De plus, via l’utilisation de nombreux Framework de Computer Vision, le suivi des clients à l’intérieur des magasins est tout à fait possible.

Dans ce but, ils se sont organisés de la manière suivante : 

– Build des Conteneurs : des images d’une taille d’environ dix à douze giga-octets contenants tous les Frameworks nécessaire et divisés en trois étapes. De plus, via l’utilisation de Docker-in-Docker, la charge de travail sur les machines est beaucoup plus configurable et moins impactant financièrement (surtout dans le cas d’utilisation du Cloud, d’instances disposant de ressources assez importantes). 

Pour la partie physique, ce fut plus compliqué car le choix technique au départ était d’utiliser des machines Raspberry.

Néanmoins, ils se sont rendu compte de quelques limitations technique (l’installation de package Python extrêmement chronophage) et se sont finalement dirigés vers des émulateurs ARM64 conteneurisés sur des serveurs X86 classiques.

Le stack final, au-delà de Kubernetes, rassemble de nombreuses technologies telles que :

  • Observabilité : Thanos, Prometheus, Fluentd, Fluentbit et cAdvisor,
  • Réseau : Après avoir testé ROS, Flannel et autre, ils ont finalement opté pour l’Host-Network à cause de certaines limitations techniques des plugins CNI mentionnés,
  • Déploiement : Ils avaient commencé par tester Ansible et ont basculé sur Kubernetes  pour son côté modulaire

Plus d’infos sur Boxy

7. K3S, le Kubernetes allégé construit mes images sans Docker

Présentée par Romain Boulanger – Cloud Engineer chez Sfeir

Il nous présente au cas pratique idéal d’un client souhaitant migrer ses applications sur Kubernetes tout en utilisant ses propres machines sans oublier l’accent sur la sécurité.

Créé par Rancher (déjà à l’œuvre sur l’orchestrateur de cluster Kubernetes bien connu), K3S est un Kubernetes allégé de certaines fonctionnalités, d’installation très rapide et présenté comme un simple exécutable et…recommandé pour tout ce qui est IoT, Intégration Continue ou les architectures RAM.

K3S présenté comme “allégé” car les fonctionnalités suivantes diffèrent par rapport à Kubernetes :

  • Legacy, alpha, non-default et les addons,
  • Utilisation de sqlite3,
  • Gestion automatique du TLS,
  • Peu de dépendances
  • Pas de port à exposer pour l’API.

De plus, Docker (tout comme ETCD) est optionnel.

Plus d’infos sur K3S

Vous pouvez retrouver les sessions de la Paris Container Day édition 2021 (ainsi que les précédentes) ici : Paris Container Day – YouTube

L’article PlugIn Kubernetes, CloudRun… Ce qu’il fallait retenir du Paris Containers Day ! est apparu en premier sur Blog TheExpert.

]]>
https://theexpert.squad.fr/theexpert/digital/devops/plugin-kubernetes-cloudrun-ce-quil-fallait-retenir-du-paris-containers-day/feed/ 0
Kubernetes Operators, Code human operational knowledge into software https://theexpert.squad.fr/theexpert/digital/devops/kubernetes-operators-code-human-operational-knowledge-into-software/ https://theexpert.squad.fr/theexpert/digital/devops/kubernetes-operators-code-human-operational-knowledge-into-software/#respond Tue, 01 Jun 2021 13:01:03 +0000 https://theexpert.squad.fr/theexpert/?p=16131 By Raouf B., Expert DevOps SQUAD Kubernetes is one of the most widely used open-source container orchestration platform. It helps to automate the deployment, scaling, self-healing, service discovery, and management of applications using containers. Stateless applications are a perfect use case to be fully managed by Kubernetes in contrast to Stateful ones which require more […]

L’article Kubernetes Operators, Code human operational knowledge into software est apparu en premier sur Blog TheExpert.

]]>
By Raouf B., Expert DevOps SQUAD

Kubernetes is one of the most widely used open-source container orchestration platform. It helps to automate the deployment, scaling, self-healing, service discovery, and management of applications using containers.

Stateless applications are a perfect use case to be fully managed by Kubernetes in contrast to Stateful ones which require more complex operations requiring manual actions. The Kubernetes operators extend Kubernetes control plane and API by adding application-specific operational knowledge, making it easier to automate repetitive maintenance operations such as upgrades, backups, recovery from failure, etc.

In other word: Think of a Kubernetes Operator as an SRE in a Software 🙂

Kubernetes Operators, a must-have for all Stateful apps ?

Kubernetes automates the Lifecyle of a stateless application, such as a web server. Without state, all pods are interchangeable. Other applications have state, they often have particulars of configuration, startup, component interdependency, persistence storage, etc. These Stateful applications have their own notion of “cluster”. In this article, we will focus on running an Apache Kafka cluster on top of Kubernetes using an open-source Operator.

Kubernetes does not and should not know about Apache Kafka! The operator teaches Kubernetes how to manage it by adding an endpoint to the API called a custom resource definition (CRD).

All the logic is implemented by taking the action based on the state of the CRD instance or simply custom resource (CR).

Making an Operator means creating a CRD and providing a program that runs in a loop watching CRs of that kind. What the Operator does in response to changes in the CR is specific to the application the Operator manages. For Apache Kafka, the actions an Operator performs can include for instance : cluster expansion or scaling, version upgrades, disk extension, rebalance, topics creation, etc.

You can find out a lot of operators in the Operatorhub.io , which is designed as a public registry for finding services backed by Kubernetes Operators, such as: Couchebase, MongoDB, Prometheus, Grafana, Redis, Kafka, etc.

Why use Strimzi with Apache Kafka?

Announced on feb 25th 2018, Strimzi is an Open-Source Project under Apache Licence 2.0 and maintained by RedHat and IMB. It focuses on running Apache Kafka on Kubernetes and provides all the container images for Apache Kafka. Strimzi simplifies operators work for deploying, managing and configuring Kafka clusters, topics and users.

Strimzi Cluster Operator Pattern

The Cluster Operator is used to deploy a Kafka cluster and other Kafka components by watching Kafka CRs. Configuring a performing Kafka cluster is not an easy task, by letting the administrator defining the desired state in YAML, the operator will make sure that what is declared is reconciled with the actual state in Kubernetes.

For a rolling update of Apache Kafka cluster, the operator logic will execute these subsequent steps in this order:

  1. Watch Kafka CR changes
  2. Apply new config to Kafka StatefulSet spec
  3. Starting from pod 0, delete the pod and allow the StatefulSet to recreate it
  4. Kafka pod will generate a new broker config
  5. Kafka is started
  6. Wait until health checks are good
  7. Repeat from step 3 for the next pod

Conclusion

Thanks to Operators, now we can easily deploy and manage complex applications on Kubernetes. For enterprise usage, the Operators can make informed decisions and free engineers from repetitive operational tasks to get focus on innovation. For local development or testing, engineers can deploy a variety of tools and components like Databases, event buses, monitoring stacks using a couple of command lines. However, we should not forget that having an Operator working, the engineers must code it first. So, think about your repetitive manual tasks, roll up your sleeves and build your own operator !

L’article Kubernetes Operators, Code human operational knowledge into software est apparu en premier sur Blog TheExpert.

]]>
https://theexpert.squad.fr/theexpert/digital/devops/kubernetes-operators-code-human-operational-knowledge-into-software/feed/ 0