Posted in Software Architecture

Kubernetes platform

Hosted Solutions
With Hosted Solutions, any given software is completely managed by the provider. The user pays hosting and management charges. Some of the vendors providing hosted solutions for Kubernetes are:

Google Kubernetes Engine (GKE)

Azure Kubernetes Service (AKS)

Amazon Elastic Container Service for Kubernetes (EKS)

DigitalOcean Kubernetes

OpenShift Dedicated

Platform9

IBM Cloud Kubernetes Service.

Turnkey Cloud Solutions
Below are only a few of the Turnkey Cloud Solutions, to install Kubernetes with just a few commands on an underlying IaaS platform, such as:

Google Compute Engine (GCE)

Amazon AWS (AWS EC2)

Microsoft Azure (AKS).

Turnkey On-Premise Solutions
The On-Premise Solutions install Kubernetes on secure internal private clouds with just a few commands:

GKE On-Prem by Google Cloud

IBM Cloud Private

OpenShift Container Platform by Red Hat.

Posted in microservices, Software Architecture

What is a service mesh, really?

What is a service mesh, really?

Figure 1: Service mesh overview

Figure 1 illustrates the service mesh concept at its most basic level. There are four service clusters (A-D). Each service instance is colocated with a sidecar network proxy. All network traffic (HTTP, REST, gRPC, Redis, etc.) from an individual service instance flows via its local sidecar proxy to the appropriate destination. Thus, the service instance is not aware of the network at large and only knows about its local proxy. In effect, the distributed system network has been abstracted away from the service programmer.

The data plane

In a service mesh, the sidecar proxy performs the following tasks:

  • Service discovery: What are all of the upstream/backend service instances that are available?
  • Health checking: Are the upstream service instances returned by service discovery healthy and ready to accept network traffic? This may include both active (e.g., out-of-band pings to a /healthcheck endpoint) and passive (e.g., using 3 consecutive 5xx as an indication of an unhealthy state) health checking.
  • Routing: Given a REST request for /foo from the local service instance, to which upstream service cluster should the request be sent?
  • Load balancing: Once an upstream service cluster has been selected during routing, to which upstream service instance should the request be sent? With what timeout? With what circuit breaking settings? If the request fails should it be retried?
  • Authentication and authorization: For incoming requests, can the caller be cryptographically attested using mTLS or some other mechanism? If attested, is the caller allowed to invoke the requested endpoint or should an unauthenticated response be returned?
  • Observability: For each request, detailed statistics, logging, and distributed tracing data should be generated so that operators can understand distributed traffic flow and debug problems as they occur.

All of the previous items are the responsibility of the service mesh data plane. In effect, the sidecar proxy is the data plane. Said another way, the data plane is responsible for conditionally translating, forwarding, and observing every network packet that flows to and from a service instance.

The control plane

The network abstraction that the sidecar proxy data plane provides is magical. However, how does the proxy actually know to route /foo to service B? How is the service discovery data that the proxy queries populated? How are the load balancing, timeout, circuit breaking, etc. settings specified? How are deploys accomplished using blue/green or gradual traffic shifting semantics? Who configures systemwide authentication and authorization settings?

All of the above items are the responsibility of the service mesh control planeThe control plane takes a set of isolated stateless sidecar proxies and turns them into a distributed system.

The reason that I think many technologists find the split concepts of data plane and control plane confusing is that for most people the data plane is familiar while the control plane is foreign. We’ve been around physical network routers and switches for a long time. We understand that packets/requests need to go from point A to point B and that we can use hardware and software to make that happen. The new breed of software proxies are just really fancy versions of tools we have been using for a long time.

Figure 2: Human control plane

However, we have also been using control planes for a long time, though most network operators might not associate that portion of the system with a piece of technology. There reason for this is simple — most control planes in use today are… us.

Figure 2 shows what I call the “human control plane.” In this type of deployment (which is still extremely common), a (likely grumpy) human operator crafts static configurations — potentially with the aid of some scripting tools — and deploys them using some type of bespoke process to all of the proxies. The proxies then consume the configuration and proceed with data plane processing using the updated settings.

Figure 3: Advanced service mesh control plane

Figure 3 shows an “advanced” service mesh control plane. It is composed of the following pieces:

  • The human: There is still a (hopefully less grumpy) human in the loop making high level decisions about the overall system.
  • Control plane UI: The human interacts with some type of UI to control the system. This might be a web portal, a CLI, or some other interface. Through the UI, the operator has access to global system configuration settings such as deploy control (blue/green and/or traffic shifting), authentication and authorization settings, route table specification (e.g., when service A requests /foo what happens), and load balancer settings (e.g., timeouts, retries, circuit breakers, etc.).
  • Workload scheduler: Services are run on an infrastructure via some type of scheduling system (e.g., Kubernetes or Nomad). The scheduler is responsible for bootstrapping a service along with its sidecar proxy.
  • Service discovery: As the scheduler starts and stops service instances it reports liveness state into a service discovery system.
  • Sidecar proxy configuration APIs: The sidecar proxies dynamically fetch state from various system components in an eventually consistent way without operator involvement. The entire system composed of all currently running service instances and sidecar proxies eventually converge. Envoy’s universal data plane API is one such example of how this works in practice.

Ultimately, the goal of a control plane is to set policy that will eventually be enacted by the data plane. More advanced control planes will abstract more of the system from the operator and require less handholding (assuming they are working correctly!).

Data plane vs. control plane summary

  • Service mesh data plane: Touches every packet/request in the system. Responsible for service discovery, health checking, routing, load balancing, authentication/authorization, and observability.
  • Service mesh control plane: Provides policy and configuration for all of the running data planes in the mesh. Does not touch any packets/requests in the system. The control plane turns all of the data planes into a distributed system.

Current project landscape

With the above explanation out of the way, let’s take a look at the current service mesh landscape.

Instead of doing an in-depth analysis of each solution above, I’m going to briefly touch on some of the points that I think are causing the majority of the ecosystem confusion right now.

Linkerd was one of the first service mesh data plane proxies on the scene in early 2016 and has done a fantastic job of increasing awareness and excitement around the service mesh design pattern. Envoy followed about 6 months later (though was in production at Lyft since late 2015). Linkerd and Envoy are the two projects that are most commonly mentioned when discussing “service meshes.”

Istio was announced May, 2017. The project goals of Istio look very much like the advanced control plane illustrated in figure 3. The default proxy of Istio is Envoy. Thus, Istio is the control plane and Envoy is the data plane. In a short time, Istio has garnered a lot of excitement, and other data planes have begun integrations as a replacement for Envoy (both Linkerd and NGINX have demonstrated Istio integration). The fact that it’s possible for a single control plane to use different data planes means that the control plane and data plane are not necessarily tightly coupled. An API such as Envoy’s universal data plane API can form a bridge between the two pieces of the system.

Nelson and SmartStack help further illustrate the control plane vs. data plane divide. Nelson uses Envoy as its proxy and builds a robust service mesh control plane around the HashiCorp stack (i.e. Nomad, etc.). SmartStack was perhaps the first of the new wave of service meshes. SmartStack forms a control plane around HAProxy or NGINX, further demonstrating that it’s possible to decouple the service mesh control plane and the data plane.

The service mesh microservice networking space is getting a lot of attention right now (rightly so!) with more projects and vendors entering all the time. Over the next several years, we will see a lot of innovation in both data planes and control planes, and further intermixing of the various components. The ultimate result should be microservice networking that is more transparent and magical to the (hopefully less and less grumpy) operator.

Key takeaways

  • A service mesh is composed of two disparate pieces: the data plane and the control plane. Both are required. Without both the system will not work.
  • Everyone is familiar with the control plane — albeit the control plane might be you!
  • All of the data planes compete with each other on features, performance, configurability, and extensibility.
  • All of the control planes compete with each other on features, configurability, extensibility, and usability.
  • A single control plane may contain the right abstractions and APIs such that multiple data planes can be used.

source: https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc

Posted in Information Technology, Software Architecture

Architecture decision record (ADR)

An architectural decision record (ADR) is a document that captures an important architectural decision made along with its context and consequences.

What is an architecture decision record?

An architecture decision record (ADR) is a document that captures an important architectural decision made along with its context and consequences.

An architecture decision (AD) is a software design choice that addresses a significant requirement.

An architecture decision log (ADL) is the collection of all ADRs created and maintained for a particular project (or organization).

An architecturally-significant requirement (ASR) is a requirement that has a measurable effect on a software system’s architecture.

All these are within the topic of architecture knowledge management (AKM).

The goal of this document is to provide a fast overview of ADRs, how to create them, and where to look for more information.

Abbreviations:

  • AD: architecture decision
  • ADL: architecture decision log
  • ADR: architecture decision record
  • AKM: architecture knowledge management
  • ASR: architecturally-significant requirement

How to start using ADRs

To start using ADRs, talk with your teammates about these areas.

Decision identification:

  • How urgent and how important is the AD?
  • Does it have to be made now, or can it wait until more is known?
  • Both personal and collective experience, as well as recognized design methods and practices, can assist with decision identification.
  • Ideally maintain a decision todo list that complements the product todo list.

Decision making:

  • A number of decision making techniques exists, both general ones and software and software architecture specific ones, for instance, dialogue mapping.
  • Group decision making is an active research topic.

Decision enactment and enforcement:

  • ADs are used in software design; hence they have to be communicated to, and accepted by, the stakeholders of the system that fund, develop, and operate it.
  • Architecturally evident coding styles and code reviews that focus on architectural concerns and decisions are two related practices.
  • ADs also have to be (re-)considered when modernizing a software sytem in software evolution.

Decision sharing (optional):

  • Many ADs recur across projects.
  • Hence, experiences with past decisions, both good and bad, can be valuable reusable assets when employing an explicit knowledge management strategy.
  • Group decision making is an active research topic.

Decision documentation:

  • Many templates and tools for decisison capturing exist.
  • See agile communities, e.g. M. Nygard’s ADRs.
  • See traditional software engineering and architecture design processes, e.g. table layouts suggested by IBM UMF and by Tyree and Akerman from CapitalOne.

Decision guidance:

  • The steps above are adopted from the Wikipedia entry on Architectural Decision
  • A number of decision making techniques exists, both general ones and software and software architecture specific ones, for instance, dialogue mapping.

How to start using ADRs with tools

You can start using ADRs with tools any way you want.

For example:

  • If you like using Google Drive and online editing, then you can create a Google Doc, or Google Sheet.
  • If you like use source code version control, such as git, then you can create a file for each ADR.
  • If you like using project planning tools, such as Atlassian Jira, then you can use the tool’s planning tracker.
  • If you like using wikis, such as MediaWiki, then you can create an ADR wiki.

How to start using ADRs with git

If you like using git version control, then here is how we like to start using ADRs with git for a typical software project with source code.

Create a directory for ADR files:

$ mkdir adr

For each ADR, create a text file, such as database.txt:

$ vi database.txt

Write anything you want in the ADR. See the templates in this repository for ideas.

Commit the ADR to your git repo.

ADR file name conventions

If you choose to create your ADRs using typical text files, then you may want to come up with your own ADR file name convention.

We prefer to use a file name convention that has a specific format.

Examples:

  • choose_database.md
  • format_timestamps.md
  • manage_passwords.md
  • handle_exceptions.md

Our file name convention:

  • The name has a present tense imperative verb phrase. This helps readability and matches our commit message format.
  • The name uses lowercase and underscores (same as this repo). This is a balance of readability and system usability.
  • The extension is markdown. This can be useful for easy formatting.

Suggestions for writing good ADRs

Characteristics of a good ADR:

  • Point in Time – Identify when the AD was made
  • Rationality – Explain the reason for making the particular AD
  • Immutable record – The decisions made in a previously published ADR should not be altered
  • Specificity – Each ADR should be about a single AD

Characteristics of a good context in an ADR:

  • Explain your organization’s situation and business priorities
  • Include rationale and considerations based on social and skills makeups of your teams

Characteristics of good Consequences in an ADR::

  • Right approach – “We need to start doing X instead of Y”
  • Wrong approach – Do not explain the AD in terms of “Pros” and “Cons” of having made the particular AD

A new ADR may take the place of a previous ADR:

  • When an AD is made that replaces or invalidates a previous ADR, a new ADR should be created

ADR example templates

ADR example templates that we have collected on the net:

For more information

Introduction:

Templates:

In-depth:

Tools:

Examples:

See also:

  • REMAP (Representation and Maintenance of Process Knowledge)
  • DRL (Decision Representation Language)
  • IBIS (Issue-Based Information System)
  • QOC (Questions, Options, and Criteria)
Posted in Information Technology, Software Architecture

ADR-Tools

Overview

Every software project includes a set of architecture decisions defining boundaries and constraints for further design and implementation.

It’s important to document those decisions somehow or else a development team might not know which decisions where made and with which assumptions.

Or they know the decision but are missing the context and the consequences and therefore decisions are blindly accepted or blindly changed.

In the following short tutorial I will show how to structure architecture decisions in so called Architecture Decision Records and how to manage them with a simple tool named ADR-Tools.

 

Architecture Decision Records (ADR)

The Agile Manifesto states that “Working software over comprehensive documentation” but this does not mean that there should be no documentation at all.

Especially for agile software projects where the architecture might adapt to new knowledge, market situations or technologies it is important to know what decisions were made, why they were made and with which assumptions.

The main problem with documentation is, that it needs to be close to the project and it needs to be short and concise or else it won’t be read or won’t be updated.

What are significant decisions that we should document in this scope?

According to my favorite author, Michael T. Nygard (Release it), significant decisions are those who “affect the structure, non-functional characteristics, dependencies, interfaces, or construction techniques

Therefore each record describes a set of forces and a single decision in their response, forces may appear in multiple Architecture Decision Records (ADR) and we store them in our project directory in doc/arch/adr-NNN.mdand we number them sequentially and monotonically.

When reversing a decision, we keep the old ADR file but we’re marking it as superseded because it still might be relevant to know that there was such a decision.

The ADR file contains these typical elements:

  • Title: The ADR file have names consisting of short noun phrases, Example: ADR 1: Use Hystrix to stabilize integration points.
  • Date: The ADR’s creation date
  • Status: The decision’s status, e.g.: “accepted“, “proposed” (if stakeholders have not approved yet), “deprecated” or “superseded
  • Context: A description of the forces at play (organizational, political, cultural, technological, social, project-local…)
  • Decision: The response to these forces, active voice, full sentences.
  • Consequences: The resulting context after applying the decision with all consequences, positive as well as neutral or negative ones.

For more detailed information, please feel free to read Michael T. Nygard: Documenting Architecture Decisions.

Of course other formats for ADRs exist, please feel free to visit https://adr.github.io/ for other tools and formats.

Installing ADR-Tools

We will be using ADR-Tools to manage our ADRs so we need to install it.

Using Mac, we may simply use the following command (using homebrew):

brew install adr-tools

Another choice e.g. for Linux is to download the latest release from GitHub here, untar the archive and add the src-path to your PATH.

ADR-Tools are a collection of bash scripts.

Initializing a Project

The first step is to initialize ADRs for our project (in this example it’s a typical Maven project).

We use adr init to initialize ADRs for our project within the specified directory …..

$ adr init doc/architecture/decisions
doc/architecture/decisions/0001-record-architecture-decisions.md

Afterwards, our project directory structure looks similar to this one:

├── doc
│   └── architecture
│       └── decisions
│           └── 0001-record-architecture-decisions.md
├── pom.xml
└── src
    ├── main
    │   ├── java
    │   └── resources
    └── test
        └── java

As we can see, a first decision already has been added to the project: It’s the decision to record our architecture decisions.

When opening the ADR file we’re able to read the following Markdown file:

# 1. Record architecture decisions
 
Date: 2018-05-26
 
## Status
 
Accepted
 
## Context
 
We need to record the architectural decisions made on this project.
 
## Decision
 
We will use Architecture Decision Records, as described by Michael Nygard in this article: http://thinkrelevance.com/blog/2011/11/15/documenting-architecture-decisions
 
## Consequences
 
See Michael Nygard's article, linked above. For a lightweight ADR toolset, see Nat Pryce's _adr-tools_ at https://github.com/npryce/adr-tools.

Creating new Architecture Decision Records

We’re ready now to create our first ADR. The command adr new allows us to create a new ADR with the given title.

$ adr new Use Hystrix to stabilize integration points
doc/architecture/decisions/0002-use-hystrix-to-stabilize-integration-points.md

This is what the generated Markdown file looks like:

# 2. Use Hystrix to stabilize integration points
 
Date: 2018-05-26
 
## Status
 
Accepted
 
## Context
 
Context here...
 
## Decision
 
Decision here...
 
## Consequences
 
Consequences here...

We’re adding another ADR:

adr new Use Thrift for data serialization between system a and system b
doc/architecture/decisions/0003-use-thrift-for-data-serialization-between-system-a-and-system-b.md

Listing Architecture Decision Records

We may list existing ADRs using adr list like this:

$ adr list
doc/architecture/decisions/0001-record-architecture-decisions.md
doc/architecture/decisions/0002-use-hystrix-to-stabilize-integration-points.md
doc/architecture/decisions/0003-use-thrift-for-data-serialization-between-system-a-and-system-b.md

Superseding a Decision

Now we will supersede a decision, for example if a new ADR supersedes our decision #3, we would type in the following command:

$ adr new -s 3 Use Avro for data serialization between system a and system b
doc/architecture/decisions/0004-use-avro-for-data-serialization-between-system-a-and-system-b.md

This produces the following new ADR file with a reference to the superseded ADR.

# 4. Use Avro for data serialization between system a and system b
 
Date: 2018-05-26
 
## Status
 
Accepted
 
Supersedes [3. Use Thrift for data serialization between system a and system b](0003-use-thrift-for-data-serialization-between-system-a-and-system-b.md)
 
## Context
 
Context here...
 
## Decision
 
Decision here...
 
## Consequences
 
Consequences here...

Of course our old decision is changed, too including a reference to the new ADR and setting its status to “Superseded”.

# 3. Use Thrift for data serialization between system a and system b
 
Date: 2018-05-26
 
## Status
 
Superseded by [4. Use Avro for data serialization between system a and system b](0004-use-avro-for-data-serialization-between-system-a-and-system-b.md)
 
## Context
 
Context here...
 
## Decision
 
Decision here...
 
## Consequences
 
Consequences here...

Generating Graphs

To gain an overview of our ADR’s relations we may generate a graph in the DOT format using adr generate graphlike this:

$ adr generate graph
digraph {
  node [shape=plaintext];
  _1 [label="1. Record architecture decisions"; URL="0001-record-architecture-decisions.html"]
  _2 [label="2. Use Hystrix to stabilize integration points"; URL="0002-use-hystrix-to-stabilize-integration-points.html"]
  _1 -> _2 [style="dotted"];
  _3 [label="3. Use Thrift for data serialization between system a and system b"; URL="0003-use-thrift-for-data-serialization-between-system-a-and-system-b.html"]
  _2 -> _3 [style="dotted"];
  _3 -> _4 [label="Superceded by"]
  _4 [label="4. Use Avro for data serialization between system a and system b"; URL="0004-use-avro-for-data-serialization-between-system-a-and-system-b.html"]
  _3 -> _4 [style="dotted"];
  _4 -> _3 [label="Supercedes"]
}

We may write this output to a file e.g. adr generate graph > generated/graph.dot

From this DOT file we may create an image e.g. using GraphViz like this:

dot -Tpng generated/graph.dot -ogenerated/graph.png

Another choice is to use an online tool like  webgraphviz here so you don’t need to install another tool.

This is what the generated graph looks like as png-image:

ADR generated graph of architecture decisions

ADR generated graph of architecture decisions

Generating Table of Contents

To include the ADRs in other documents we may generate a table of contents for our ADRs using adr generate toc like this:

$ adr generate toc

This returns the following Markdown code:

# Architecture Decision Records
 
* [1. Record architecture decisions](0001-record-architecture-decisions.md)
* [2. Use Hystrix to stabilize integration points](0002-use-hystrix-to-stabilize-integration-points.md)
* [3. Use Thrift for data serialization between system a and system b](0003-use-thrift-for-data-serialization-between-system-a-and-system-b.md)
* [4. Use Avro for data serialization between system a and system b](0004-use-avro-for-data-serialization-between-system-a-and-system-b.md)

Linking Architecture Decision Records

When ADRs are linked somehow we want to document this and adr link eases this for us.

Let’s use an example where ADR #4 amends ADR #2 so that we could link both with the following command:

$ adr link 4 Amends 2 "Amended by"

Now our graph looks like this:

adr generate graph
digraph {
  node [shape=plaintext];
  _1 [label="1. Record architecture decisions"; URL="0001-record-architecture-decisions.html"]
  _2 [label="2. Use Hystrix to stabilize integration points"; URL="0002-use-hystrix-to-stabilize-integration-points.html"]
  _1 -> _2 [style="dotted"];
  _2 -> _4 [label="Amended by"]
  _3 [label="3. Use Thrift for data serialization between system a and system b"; URL="0003-use-thrift-for-data-serialization-between-system-a-and-system-b.html"]
  _2 -> _3 [style="dotted"];
  _3 -> _4 [label="Superceded by"]
  _4 [label="4. Use Avro for data serialization between system a and system b"; URL="0004-use-avro-for-data-serialization-between-system-a-and-system-b.html"]
  _3 -> _4 [style="dotted"];
  _4 -> _3 [label="Supercedes"]
  _4 -> _2 [label="Amends"]
}

Or as an image:

Updated Architecture Decision Graph

Updated Architecture Decision Graph

In addition both ADR files were updated:

ADR #2 now looks like this one:

# 2. Use Hystrix to stabilize integration points
 
Date: 2018-05-26
 
## Status
 
Accepted
 
Amended by [4. Use Avro for data serialization between system a and system b](0004-use-avro-for-data-serialization-between-system-a-and-system-b.md)
 
## Context
 
Context here...
 
## Decision
 
Decision here...
 
## Consequences
 
Consequences here...

ADR #4 has been changed to this:

# 4. Use Avro for data serialization between system a and system b
 
Date: 2018-05-26
 
## Status
 
Accepted
 
Supercedes [3. Use Thrift for data serialization between system a and system b](0003-use-thrift-for-data-serialization-between-system-a-and-system-b.md)
 
Amends [2. Use Hystrix to stabilize integration points](0002-use-hystrix-to-stabilize-integration-points.md)
 
## Context
 
Context here...
 
## Decision
 
Decision here...
 
## Consequences
 
Consequences here...

 

 

Posted in Information Technology, Security, Software Architecture

OWASP ASVS Cheat Sheet

Objective

This index have for objective to indicate to help an OWASP Application Security Verification Standard (ASVS) user to clearly identify which cheat sheets are useful for each section during his usage of the ASVS.

This index is based on the version 4.x of the ASVS.

V1: Architecture, Design and Threat Modeling Requirements

V1.1 Secure Software Development Lifecycle Requirements

Threat Modeling Cheat Sheet.

Abuse Case Cheat Sheet.

Attack Surface Analysis Cheat Sheet.

V1.2 Authentication Architectural Requirements

None.

V1.3 Session Management Architectural Requirements

None.

V1.4 Access Control Architectural Requirements

Docker Security Cheat Sheet.

V1.5 Input and Output Architectural Requirements

Abuse Case Cheat Sheet.

Deserialization Cheat Sheet.

V1.6 Cryptographic Architectural Requirements

Cryptographic Storage Cheat Sheet.

Key Management Cheat Sheet.

V1.7 Errors, Logging and Auditing Architectural Requirements

Logging Cheat Sheet.

V1.8 Data Protection and Privacy Architectural Requirements

Abuse Case Cheat Sheet.

User Privacy Protection Cheat Sheet.

V1.9 Communications Architectural Requirements

Transport Layer Protection Cheat Sheet.

TLS Cipher String Cheat Sheet.

V1.10 Malicious Software Architectural Requirements

Third Party Javascript Management Cheat Sheet.

Virtual Patching Cheat Sheet.

V1.11 Business Logic Architectural Requirements

Abuse Case Cheat Sheet.

V1.12 Secure File Upload Architectural Requirements

None.

V1.13 API Architectural Requirements

REST Security Cheat Sheet.

V1.14 Configuration Architectural Requirements

None.

V2: Authentication Verification Requirements

V2.1 Password Security Requirements

Choosing and Using Security Questions Cheat Sheet.

Forgot Password Cheat Sheet.

Credential Stuffing Prevention Cheat Sheet

V2.2 General Authenticator Requirements

Authentication Cheat Sheet.

Transport Layer Protection Cheat Sheet.

TLS Cipher String Cheat Sheet.

V2.3 Authenticator Lifecycle Requirements

None.

V2.4 Credential Storage Requirements

Password Storage Cheat Sheet.

V2.5 Credential Recovery Requirements

Choosing and Using Security Questions Cheat Sheet.

Forgot Password Cheat Sheet.

V2.6 Look-up Secret Verifier Requirements

None.

V2.7 Out of Band Verifier Requirements

Forgot Password Cheat Sheet.

V2.8 Single or Multi Factor One Time Verifier Requirements

None.

V2.9 Cryptographic Software and Devices Verifier Requirements

Cryptographic Storage Cheat Sheet.

Key Management Cheat Sheet.

V2.10 Service Authentication Requirements

None.

V3: Session Management Verification Requirements

V3.1 Fundamental Session Management Requirements

None.

V3.2 Session Binding Requirements

Session Management Cheat Sheet.

V3.3 Session Logout and Timeout Requirements

Session Management Cheat Sheet.

V3.4 Cookie-based Session Management

Session Management Cheat Sheet.

Cross-Site Request Forgery Prevention Cheat Sheet.

V3.5 Token-based Session Management

JSON Web Token Cheat Sheet for Java.

REST Security Cheat Sheet.

V3.6 Re-authentication from a Federation or Assertion

None.

V3.7 Defenses Against Session Management Exploits

Session Management Cheat Sheet.

Transaction Authorization Cheat Sheet.

V4: Access Control Verification Requirements

V4.1 General Access Control Design

Access Control Cheat Sheet.

Authorization Testing Automation.

V4.2 Operation Level Access Control

Insecure Direct Object Reference Prevention Cheat Sheet.

Cross-Site Request Forgery Prevention Cheat Sheet.

Authorization Testing Automation.

V4.3 Other Access Control Considerations

REST Assessment Cheat Sheet.

V5: Validation, Sanitization and Encoding Verification Requirements

V5.1 Input Validation Requirements

Mass Assignment Cheat Sheet.

Input Validation Cheat Sheet.

V5.2 Sanitization and Sandboxing Requirements

Server Side Request Forgery Prevention Cheat Sheet.

XSS Prevention Cheat Sheet.

DOM based XSS Prevention Cheat Sheet.

Unvalidated Redirects and Forwards Cheat Sheet.

V5.3 Output encoding and Injection Prevention Requirements

XSS Prevention Cheat Sheet.

DOM based XSS Prevention Cheat Sheet.

HTML5 Security Cheat Sheet.

Injection Prevention Cheat Sheet.

Injection Prevention Cheat Sheet in Java.

Input Validation Cheat Sheet.

LDAP Injection Prevention Cheat Sheet.

OS Command Injection Defense Cheat Sheet.

Protect File Upload Against Malicious File.

Query Parameterization Cheat Sheet.

SQL Injection Prevention Cheat Sheet.

Unvalidated Redirects and Forwards Cheat Sheet.

Bean Validation Cheat Sheet.

XXE Prevention Cheat Sheet.

XML Security Cheat Sheet.

V5.4 Memory, String, and Unmanaged Code Requirements

None.

V5.5 Deserialization Prevention Requirements

Deserialization Cheat Sheet.

XXE Prevention Cheat Sheet.

XML Security Cheat Sheet.

V6: Stored Cryptography Verification Requirements

V6.1 Data Classification

Abuse Case Cheat Sheet.

User Privacy Protection Cheat Sheet.

V6.2 Algorithms

Cryptographic Storage Cheat Sheet.

Key Management Cheat Sheet.

V6.3 Random Values

None.

V6.4 Secret Management

Key Management Cheat Sheet.

V7: Error Handling and Logging Verification Requirements

V7.1 Log Content Requirements

Logging Cheat Sheet.

V7.2 Log Processing Requirements

Logging Cheat Sheet.

V7.3 Log Protection Requirements

Logging Cheat Sheet.

V7.4 Error Handling

Error Handling Cheat Sheet.

V8: Data Protection Verification Requirements

V8.1 General Data Protection

None.

V8.2 Client-side Data Protection

None.

V8.3 Sensitive Private Data

None.

V9: Communications Verification Requirements

V9.1 Communications Security Requirements

HTTP Strict Transport Security Cheat Sheet.

Transport Layer Protection Cheat Sheet.

TLS Cipher String Cheat Sheet.

V9.2 Server Communications Security Requirements

None.

V10: Malicious Code Verification Requirements

V10.1 Code Integrity Controls

Third Party Javascript Management Cheat Sheet.

V10.2 Malicious Code Search

None.

V10.3 Deployed Application Integrity Controls

Docker Security Cheat Sheet.

V11: Business Logic Verification Requirements

V11.1 Business Logic Security Requirements

Abuse Case Cheat Sheet.

V12: File and Resources Verification Requirements

V12.1 File Upload Requirements

Protect File Upload Against Malicious File.

V12.2 File Integrity Requirements

Protect File Upload Against Malicious File.

Third Party Javascript Management Cheat Sheet.

V12.3 File execution Requirements

None.

V12.4 File Storage Requirements

None.

V12.5 File Download Requirements

None.

V12.6 SSRF Protection Requirements

Server Side Request Forgery Prevention Cheat Sheet.

Unvalidated Redirects and Forwards Cheat Sheet.

V13: API and Web Service Verification Requirements

V13.1 Generic Web Service Security Verification Requirements

Web Service Security Cheat Sheet.

Server Side Request Forgery Prevention Cheat Sheet.

V13.2 RESTful Web Service Verification Requirements

REST Assessment Cheat Sheet.

REST Security Cheat Sheet.

Cross-Site Request Forgery Prevention Cheat Sheet.

V13.3 SOAP Web Service Verification Requirements

XML Security Cheat Sheet.

V13.4 GraphQL and other Web Service Data Layer Security Requirements

None.

V14: Configuration Verification Requirements

V14.1 Build

Docker Security Cheat Sheet.

V14.2 Dependency

Docker Security Cheat Sheet.

Vulnerable Dependency Management Cheat Sheet.

V14.3 Unintended Security Disclosure Requirements

Error Handling Cheat Sheet.

V14.4 HTTP Security Headers Requirements

Content Security Policy Cheat Sheet.

V14.5 Validate HTTP Request Header Requirements

None.

 

Posted in Devops, Software Architecture, Software Engineering

AWS Lamba Cheat Sheet

Preparing Deployment Packages

Python

To add extra Python modules into the package use “-t ” to install them into the package

pip install <module name> -t <package path>
pip3 install <module name> -t <package path>

On current Debian/Ubuntu you might get a

DistutilsOptionError: can't combine user with prefix, exec_prefix/home, or install_(plat)base

in this case add a “–system” switch to your call, e.g.

pip install <module name> --system -t <package path>

Import/Export

Import is possible in the code editor (File menu). Export is possible via the global “Actions” menu.

Misc

Posted in Information Technology, Software Architecture, Software Engineering

RESTful API cheatsheet

Status codes

200 OK Successful get, patch (return a JSON object)
201 Created Successful post (return a JSON object)
202 Accepted Successful post, delete, path – async
204 No content Successful delete
206 Partial content Successful get – async

Error status

401 Unauthorized Not authenticated
403 Forbidden Authenticated, but no permissions
422 Unprocessable entity Validation

Errors

HTTP/1.1 401 Unauthorized
Content-Type: application/json
{
  'id': 'auth_failed',
  'message': "You're not logged in."
}

Here’s an example of a possible error reply.

Versioning

GET /api/foo
Accept: application/json; version=1

You can pass a version=x to the Accept request header. Info here

Authentication

curl -is https://$TOKEN@api.service.com/

Methods

GET /articles/1 read, returns 200
PUT /articles/1 edit (or path), returns 200
DELETE /articles/1 delete, returns 200
POST /articles create, returns 201
GET /articles list, returns 200

References

 

Posted in microservices, Software Architecture

Microservices Architectures: What Is Fault Tolerance?

In this article, we discuss an important property of microservices, called fault tolerance.

You Will Learn

  • What is Fault Tolerance?
  • Why is fault tolerance important in microservices architecture?
  • How do you achieve fault tolerance?

What Is Fault Tolerance?

Microservices need to be extremely reliable.

When we build a microservices architecture, there are a large number of small microservices, and they all need to communicate with one another.

Lets consider the following example:

Basic microservices architecture

Let’s say Microservice5 is down at some point in time.

All the other microservices are directly or indirectly dependent on it, so they all go down as well.

The solution to this problem is to have a fallback in case a microservice fails. This aspect of a microservice is called fault tolerance.

Implementing Fault Tolerance With Hystrix

A popular framework used to implement fault tolerance is Hystrix, a Netflix open source framework. Here is some sample Hystrix code:

@GetMapping("/fault-tolerance-example")
@HystrixCommand(fallbackMethod="fallbackRetrieveConfguration")
public LimitConfiguration retrieveConfiguration() {
throw new RuntimeException("Not Available");
}

public LimitConfiguration fallbackRetrieveConfiguration() {
return new LimitConfiguration(999, 9);
}

Hystrix enables you to specify the fallback method for each of your service methods. If the method throws an exception, what should be returned to the service consumer?

Here, if retrieveConfiguration() fails, then fallbackRetrieveConfiguration is called, which returns a hardcoded LimitConfiguration instance:

Hystrix and Alerts

With Hystrix, you can also configure alerts at the backend. If a service starts failing continuously, you can send alerts to the maintainance team.

Hystrix Is Not a Silver Bullet

Using Hystrix and fallback methods is appropriate for services that handle non-critical information.

However, it is not a silver bullet.

Consider, for instance, a service that returns the balance of a bank account. You cannot provide a default hardcoded value back.

Using Sufficient Redundancy

It is important to design critical services in a fail safe manner. It is important to build enough redundancy into the system to ensure that the services do not fail.

Have Sufficient Testing

It is important to test for failure. Bring a microservice down. See how your system reacts.

Chaos Monkey from Netflix is a good example of this.

Summary

In this article, we discussed fault tolerance. We saw how fault tolerance is essential in a microservices architecture. We then saw how it can be implemented at the code level using frameworks such as Hystrix.

Posted in Information Technology, microservices, Software Architecture

What Is Service Discovery?

When we talk about a microservices architecture, we refer to a system with a large number of small services, working with each other:

Basic Microservices Architecture

Basic Mircoservices Architecture

An important feature of such architectures is auto-scaling. The number of instances of a microservice varies based on the system load. Initially, you could have 5 instances of Microservice5, which go up later to 20, 100, or 1000!

Two important questions arise

  • How does Microservice4 know how many instances of Microservice5 are present, at a given time?
  • In addition, how does it distribute the load among all of them?

Hardcoding URLs Is Not an Option

One way to do this is to hard-code the URLs of Microservice5 instances, within Microservice4. That means every time the number of Microservice5 instances changes (with the addition of new one or the deletion of existing one), the configuration within Microservice4 needs to change. This is a big headache.

Using Service Discovery

Ideally, you want to change the number of instances of Microservice5 based on the load, and make Microservice4 dynamically aware of the instances.

That’s where the concept of Service Discovery comes into the picture.

The component that provides this service is generally called a naming server.

All instances of all the microservices register themselves with the naming server. Whenever a microservice wants to talk to another microservices, it asks the naming server about the available instances.

In the example above, whenever a new instance of Microservice5 is launched, it registers with the naming server. When Microservice4 wants to talk to Microservice5, it asks the naming server: what are the available instances of Microservice5?

Another Example of Service Discovery

Using Service Discovery to identify microservice instances helps keep things dynamic.

Let’s say there is a service for currency conversion:

The CurrencyConversionService (CCS) talks to the ForexService. At a certain point of time, these services have two instances each:

However, there could be a time where there are five instances of the ForexService (FS):

In that case, CurrencyConversionService needs to make sure that the load is evenly distributed across all the ForexService instances. It needs to answer two important questions:

  • How does the CurrencyConversionService know how many instances of ForexService are active?
  • How does the CurrencyConversionService distribute the load among those active instances?

When a CCS microservice instance is brought up, it registers with Eureka. The same thing happens with all instances of FS as well.

When a CCS instance needs to talk to an FS instance, it requests information from Eureka. Eureka would then return the URLS of the two FS instances active at that time. Here, the application makes use of a client-side load distribution framework called Ribbon. Ribbon ensures proper load distribution over the two FS instances, for events coming in from the CCS.

Summary

In this video, we talked about microservice service discovery. We saw that microservices need to be able to communicate with each other. The number of instances of a microservice changes over time, depending on the load. Service discovery enables us to dynamically adapt to new instances and distribute load among microservices.

Posted in Information Technology, microservices, Software Architecture

Why Centralized Configuration?

When we talk about a microservices architecture, we visualize a large number of small microservices talking to each other. The number of microservices depends on the size of the enterprise.

Basic Microservices ArchitectureBasic Microservices Architecture

The interesting part is that each of these microservices can have their own configuration.

Such configurations include details like:

  • Application configuration.
  • Database configuration.
  • Communication Channel Configuration – queues and other infrastructure.
  • URLs of other microservices to talk to.

In addition, each microservice will have a separate configuration for different environments, such as development, QA, and production.

If maintaining a single configuration for a large application is difficult, imagine maintaining configurations for hundreds of microservices in different environments.

Centralized Config Server to the Rescue

That’s where a centralized configuration server steps in.

Configuration for all microservices (for all environments) is stored at one place — a centralized configuration store.

When a microservice needs its configuration, it provides an ID at launch — a combination of the name of the microservice and the environment.

The centralized config server looks up the configuration and provides the configuration to the microservice.

Ensure that the configuration in a centralized config server is secured and has role-based access.

Introducing Spring Cloud Config Server

Spring Cloud Config Server is one of the popular implementations of a cloud config server.

Spring Cloud Config Server enables you to store all the configurations for multiple microservices for different environments in a git or SVN Repository. A set of folder structures and conventions needs to be followed for the setup to work.

Spring Cloud Config Server

A microservice can connect to the config server and identify itself, and also specify the instance it represents. This enables it to get the required configuration.

The setup ensures that the operations team does not need to take time out to configure the individual microservices on a case-by-case basis. All that they need to worry about is configuring the centralized config server, and starting to put relevant configurations into the git repository.

Automatically Picking Up Configuration Changes

An interesting feature present with the Spring Cloud Config Server is auto refresh. Whenever a change is committed to the git repository, configuration in the application is auto-refreshed.

Summary

In this article, we looked at why we need centralized configuration in microservices-based applications. We looked at how the Spring Cloud Config Server manages centralized configuration.