Ravi Srivastava: 2022

Thursday, December 29, 2022

Integration - Lambda, API Gateway, OKTA/oAuth, WAF

WAF

Load Balancer

OKTA

Lambda

API Gateway

Terraform

Install | Terraform | HashiCorp Developer

Extras

Thursday, December 8, 2022

API Gateway Configuration with Other services

OKTA and API Gateway Config

1. Subscribe to Okta and configure a OAuth2 client in Okta.

· Create Application Okta

o Create Client ID

o Create Client Secrets

· Configure API

o Create Audience

o Create Scopes

o Generate oAuth Token

· Get token_endpoint

· Using token_endpoint get access_token

2. Deploy a sample API Gateway HTTP API with a test endpoint

· Login in AWS console, select API Gateway

· Create API

o Select HTTP API option and click on Build button

o Enter API Name and hit "Review and create" button and then press create

o Select Routes under develop option from menu list

· Select Create button

· Select method (Get/Put etc)

§ Enter path (like /users or /pet/{id})

§ Method will be created

· Select created method

§ Select Attach Authorizer button

· If any existing authorizer exist select from list

· If authorizer does not exists

· Select create and attach authorizer

· Select Authorizer Type - Select JWT

· Enter Authorizer name and details (issuer details, Audience, Scope) and save

o Select Integration

· Create an integration to attach (configured for this API)

§ Select HTTP URI

· Select Integration Details

· Method type, API URL , timeout

§ If Stage exist select deploy

· Otherwise create stage

§ Select throttling from Protect menu

· Enter throttling information as needed (route throttling, Account throttling)

§ Select metrices and logging details as needed

§ Select Deploy and select Stage for deployment

o Under Optimize option

o Select Cache Setting

· Enter details for caching related

o Select stage option

o Select Setting tab

· Enable API cache

· API Gateway is ready for Okta and API Gateway integration based on oAuth Token

WAF deployed on API Gateway

Select REST API and build

Enter setting details (API name and other related details) and create API

Under API Resources list, in middle section (resources),

select Action and create method (chose one of the option get, put etc), select tick mark

Under Get define Integration type and integration details and save

Deploy this API after creating new stage or using existing stage

In Middle section Stage be display and right section will have stage editor.

Select setting from editor, enable API Cache if needed, Apply client certificate if exist and select existing WebACL or create new

Click WebACL, it will open new AWS console

Enter all details and select Resource type as regional resource and select region

Select Associate AWS resource option

It will open new window where you select API Gateway resource type

Select API Gateway as resource where you want to deploy WAF, click Add

Select next

Create new rules or use existing rule and add into this WebACL

Select Default web ACL action (Allow or blocks)

Add token list to WebACL

Click next

Select rules priority based on needs

Add Cloudwatch Metrics and select next

Review all details for WebACL and select Create WebACL

Similarly we can select any other resources except NLB (WebACL does not apply to Network Load balancer)

Go to API Gateway select API which needs WAF protection

Select Stage and select setting

Select Web ACL from list and save

This will allow API which goes through API Gateway will be protect through WAF

WAF is deployed on API Gateway for those API which needs to be protect

Thursday, December 1, 2022

AWS API Gateway - OKTA and Auth0

https://us-east-1.console.aws.amazon.com/lambda/home?region=us-east-1#/functions/Lambda2prgram?newFunction=true&tab=configureAWS API Gateway - Okta and Auth0

The client application will invoke Okta /token endpoint using OAuth2 client_credentials grant to get a JWT access token
Okta will return a JWT access token
Invoke the API configured in AWS API Gateway by passing the Okta JWT token in Authorization header
AWS API gateway’s built-in JWT Authorizer will validate the JWT token by getting the public key from Okta’s jwks_uri. There are some additional validations that are performed.
Refer https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api-jwt-authorizer.html
Built-in JWT Authorizer will return the status of token validation to AWS API gateway. This happens in the background.
API gateway will forward the request to target API endpoint if all the validations are successful. If the token is invalid or the required scopes are not present, API gateway will return an error response.
API endpoint will return the response back to API gateway.
API gateway will return the response back to client application.

Reference

Tuesday, November 22, 2022

Istio service mesh

An Istio service mesh is logically split into a data plane and a control plane.

The data plane is composed of a set of intelligent proxies (Envoy) deployed as sidecars. These proxies mediate and control all network communication between microservices. They also collect and report telemetry on all mesh traffic.
The control plane manages and configures the proxies to route traffic.

In Istio, configure a single service mesh to span any number of clusters, or can configure a single mesh to include multiple clusters

Envoy Proxy:

Processes the inbound/outbound traffic from inter-service and service-to-external-service transparently. Istio components that interact with data plane traffic. Envoy proxies are deployed as sidecars to services. It will have Service entry (fully qualified name)

Some of the Istio features and tasks enabled by Envoy proxies include:

Traffic control features: enforce fine-grained traffic control with rich routing rules for HTTP, gRPC, WebSocket, and TCP traffic.
Network resiliency features: setup retries, failovers, circuit breakers, and fault injection.
Security and authentication features: enforce security policies and enforce access control and rate limiting defined through the configuration API.
Pluggable extensions model based on Web-Assembly that allows for custom policy enforcement and telemetry generation for mesh traffic

Istiod:

Istiod provides service discovery, configuration and certificate management. Istiod converts high level routing rules that control traffic behavior into Envoy-specific configurations, and propagates them to the sidecars at runtime

Pilot: Pilot provides service discovery for the Envoy sidecars, traffic management capabilities for intelligent routing (e.g., A/B tests, canary deployments, etc.), and resiliency (timeouts, retries, circuit breakers, etc.)

Citadel: Citadel enables strong service-to-service and end-user authentication with built-in identity and credential management. It provides encryption of traffic between Envoy Sidecar Proxies using mutual TLS
Galley: Galley is Istio’s configuration validation, ingestion, processing and distribution component. It is responsible for insulating the rest of the Istio components from the details of obtaining user configuration from the underlying platform (e.g. Kubernetes).

Virtual services route traffic to a given destination and use destination rules to configure what happens to traffic for that destination.

Ingress gateway configuration lets HTTP traffic from Istio ingress gateway into the mesh on port 80. To specify routing and for the gateway to work as intended, we also bind the gateway to a virtual service.

setup Istio service mesh in AWS EKS

Prerequisites:

· kubectl v1.18.0

· helm v3.2.1

· Istio 1.8.2

· terraform v0.12.30

· aws-iam-authenticator

· Programming access to AWS account.

Complete view for Istio:

· Istio Gateway - connect outside to Service Mesh clusters

· Ingress Gateway - request coming in / request connecting to Service mesh

It is Envoy proxies, running on separate POD as Istio proxy container, it runs only Istio Envoy Proxy nothing else on this container

§ Create Virtual Service
§ Create Destination Rule
§ Attach routing rules using virtual service and Destination Rule to Envoy proxies

Egress Gateway - Connecting from Mesh to outside

It is Envoy proxies, running on separate POD as Istio proxy container, it runs only Istio Envoy Proxy nothing else on this container

§  Create Virtual Service
§  Create Destination Rule
§  Attach routing rules using virtual service and Destination Rule to Envoy proxies

· Deployment for Ingress Gateway:

Running Envoy Proxies POD

Service for Ingress Gateway to connect to envoy Proxy

Service Object (Gateway Object) to enable Ingress Gateway to Receive Traffic from outside
Virtual Service to link routing services to routing rules to Ingress Gateway (Istio Proxy)

Gateways object will host details which will allow host / external world connect to the application and filters other requests.

Ingress Gateway Service come with Istio installation
There are two types of virtual service, first one at ingress gateway layer and other one is inside the service mesh.

Virtual Service enable further routing using "gateway", this "gateway" allow request to enter into Mesh and forward to Ingress Gateway/Proxy.
Other Virtual service will allow inter service communications and will configure on each POD with Istio Service Mesh

Launch k8s cluster in AWS EKS using terraform. deploy EKS cluster. prepare namespaces to Istio service mesh. deploy each application to own namespace.
Kiali is an observability console for Istio with service mesh configuration and validation capabilities

- Building an Istio service mesh for a microservices application deployed on Kubernetes

- K8, AWS ALB WITH ISTIO INGRESSGATEWAY:

All traffic through the IngressGateway, we can route traffic differently depending on hostnames, most easily by using prefixes, by using Virtual Services.

References: