Docker Content trust

When transferring data among networked systems, trust is a central concern.

In particular, when communicating over an untrusted medium such as the internet, it is critical to ensure the integrity and the publisher of all the data a system operates on.

Docker Content Trust(DCT) provides strong cryptographic guarantees over what code and what versions of software are being run in your infrastructure.

When a publisher using Docker Content Trust pushes an image to a remote registry, Docker Engine signs the image locally with the publisher’s private key.

When the user later pulls this image, Docker Engine uses the publisher’s public key to verify that the image is exactly what the publisher created, has not been tampered with, and is up to date.

There are 4 major steps to setup DCT.

1)Generate Docker Content Trust Key

2)Add the Signer to the Docker Repository

3)Sign the Image

4)Enable Content Trust at the Docker host

By following above 4 steps we can set DCT.

Software Resilience Testing

Software resilience testing is a method of software testing that focuses on ensuring that applications will perform well in real-life or chaotic conditions.

 In other words, it tests an application’s resiliency, or ability to withstand stressful or challenging factors.

Resilience testing is one part of non-functional software testing that also includes compliance, endurance, load and recovery testing.

Since failures can never be avoided, resilience testing ensures that software can continue performing core functions and avoid data loss even when under stress.

In today’s world, system downtime is not an option. If a user can’t access an application once, chances are that they will never use it again. Resiliency, which in simple terms is the ability of a system to gracefully handle and recover from failures, thus becomes critical. 

Testing resiliency ensures the system’s ability to absorb the impact of a problem while continuing to provide an acceptable level of service to the business. 

This concept was originally introduced by Netflix in the Principles of Chaos Engineering.

To build your test strategies for resilient systems, you should:

1)Conduct a failure mode analysis by reviewing the design of the system. In simple terms, this means identifying all the components, internal and external interfaces, and identifying potential failures at every point. Once failure points are identified, validate that there are alternatives to failure. 

2)Validate data resiliency, i.e. that there is a mechanism for data to be available to applications if the system that originally hosted the data fails. Verify that the data backup process is either documented or automated.

 If automated, validate that the automated script backs up data correctly, maintaining integrity and schema.

3)From an infrastructure standpoint, configure and test health probes for load balancing and traffic management. These ensure that the system is not limited to a single region for deployment in case of latency issues.

4)From an application standpoint, conduct fault injection tests for every application in your system. Scenarios include shutting down interfacing systems, deleting certificates, consuming system resources, and deleting data sources.

5)Conduct critical tests in production with well-planned canary deployments. 

Validate that there is an automated rollback mechanism for code in production in case of failure.

Install and Run Gremlin on Windows

Below steps need to be followed to install Gremlin on windows.

• Signup for Gremlin Account using below link.   https://app.gremlin.com/signup
• Download the Gremlin installer gremlin_installer.msi
• Run the installer by double-clicking on the downloaded file.
• Windows, by default, prevents this from running, and shows a Windows protected your PC dialog box.
• Proceed with the installation by clicking on More info. 
• This will display another button at the bottom, Run anyway. Click that button to continue.
• Once the istallation done,we can locate Gremlin config file under below location.
•  C:\ProgramData\Gremlin\Agent\config.yaml
• Signin to Grimlin account.
• Go to "Team Settings" and Copy "TeamID" and "SecretKey".
• Open a command prompt and run "gremlin init"
• You will be prompted to enter the following values.

          Please input your Team ID:

          Please input your Team Secret:

•  Once provided with above values Gremlin will be initiated.

Failure Injection Testing

Fault Injection is a technique for enhancing the testing quality by involving the intentional faults in the software. 

Fault injection is often in stress testing and it is considered as an important part of developing robust software.

Fault injection Methods:

Compile-Time Injections - It is a fault injection technique where source code is modified to inject simulated faults into a system.

Run-Time Injections - It makes use of software trigger to inject a fault into a software system during run time. The Trigger can be of two types, Time Based triggers and Interrupt Based Triggers.

Tools used for Software Fault Injection:

Following are the tools used for fault injection purposes:

BStorm Beyond Security==> http://www.beyondsecurity.com/

The Mu Service Analyzer Mu Dynamics==>www.mudynamics.com

Holodecksecurity Innovation==>www.securityinnovation.com

Xception Critical software==>http://www.criticalsoftware.co

Suite of Chaos tools for AWS

 Chaos Monkey is a software tool that was developed by Netflix engineers to test the resiliency and recoverability of their Amazon Web Services (AWS). 

The software simulates failures of instances of services running within Auto Scaling Groups (ASG) by shutting down one or more of the virtual machines.

Chaos Monkey works on the principle that the best way to avoid major failures is to fail constantly.

Chaos Monkey is not alone in the army. Since it was developed and its popularity rose, a whole suite of Chaos tools has been developed to simulate outages and test system response times.

Chaos engineers now have the Simian Army to work with and Chaos Monkey falls in ranks with:

• Chaos Kong drops a whole AWS Region.
• Chaos Gorilla drops a whole AWS Availability Zone.
• Latency Monkey simulates network outages or delays.
• Doctor Monkey performs health checks.
• Janitor Monkey identifies unused resources.
• Conformity Monkey identifies non-conforming instances based on a set of rules.
• Security Monkey tests for known vulnerabilities. End of life in 2020, with alternatives available.
• 10-18 Monkey detects configuration and run-time problems in instances serving customers in multiple geographic regions.

ESB

 An enterprise service bus (ESB) is a bus-like architecture that helps integrate diverse applications and services in an enterprise. 

It incorporates a messaging engine, data integration and routing capabilities, web services, and analytics capabilities. 

You can use an ESB for the following:

• Decouple product components and allocate them to different compute resources
• Support migration between servers, private and public clouds, and hybrid cloud environments
• Support loose coupling - thereby enabling you to readily integrate existing systems and incorporate new technologies as they emerge
• Creation of new web services and functions seamlessly with in-built message brokering
• Build solutions with visual tooling, interactive debugging, and data mapping
• Analyze integration flows with advanced, customizable analytics capabilities

ESB’s guiding principles are:

• Orchestration - integrates two or more applications and services to synchronize data and process.
• Transformation - transforms data from canonical to application specific format.
• Transportation - protocol negotiation between multiple formats like HTTP, JDBC, JMS, and FTP etc.
• Mediation - multiple interfaces for supporting multiple versions of a service.
• Non-functional consistency - transaction management and security.

Below are some of the ESB products:

• Red Hat JBoss Fuse. 
• Mule ESB. 
• IBM Websphere ESB.
• Oracle ESB.
• Microsoft BizTalk.
• IBM DataPower Gateway

Salesforce Sandbox Types

 The development and testing environment within Salesforce is termed as Salesforce Sandbox. The sandbox copy of Salesforce is provisioned with all code, data, and configuration.

 Salesforce Sandbox is not a separate version of the organization, instead, it is just a replica of the original one. Any change in the organization will not be automatically reflected in Salesforce Sandbox.

 A snapshot of the production environment on the date on which it is created is known as Salesforce Sandbox.

The Sandbox environment is created for several purposes like for training, development, testing, and others, even without affecting data and configuration in the Salesforce production instance.

Sandbox Types:

Developer Sandbox:

A Developer sandbox is intended for development and testing in an isolated environment. A Developer Sandbox includes a copy of your production org’s configuration (metadata).

Points to remember:

1)Storage limit is 200MB.

2)Refreshing limits is once per day.

Developer Pro Sandbox:

A Developer Pro sandbox is intended for development and testing in an isolated environment and can host larger data sets than a Developer sandbox. 

A Developer Pro sandbox includes a copy of your production org’s configuration (metadata). Use a Developer Pro sandbox to handle more development and quality assurance tasks and for integration testing or user training.

Points to remember:

1)Refresh limit is once per day.

2)Storage limit is of Max 1GB.

Partial Copy Sandbox:

A Partial Copy sandbox is intended to be used as a testing environment. This environment includes a copy of your production org’s configuration (metadata) and a sample of your production org’s data as defined by a sandbox template. 

Use a Partial Copy sandbox for quality assurance tasks such as user acceptance testing, integration testing, and training.

Points to remember:

1)You can refresh a Partial Data sandbox 5 days after you created or last refreshed it

2) If you delete a Partial Data sandbox within those 5 days, you need to wait until after the 5 day period, from the date of last refresh or creation, to replace it.

3)Storage limit is of Max 5GB and and maximum 10,000 record per selected object..

Full Copy Sandbox:

A Full sandbox is intended to be used as a testing environment. Only Full sandboxes support performance testing, load testing, and staging. Full sandboxes are a replica of your production org, including all data, such as object records and attachments, and metadata.

When you create a Full sandbox, you also have to decide how much field tracking history and Chatter activity to include.

The default is to omit field tracking, but you can include up to 180 days of field tracking. If you track field history for many objects in your production org, specify fewer days to avoid generating an excessive amount of data.

Points to remember:

1)You can refresh a Full sandbox 29 days after you created or last refreshed it.

2) If you delete a Full sandbox within those 29 days, you need to wait until after the 29 day period, from the date of last refresh or creation, to replace it.

3)Storage limits are Same like prod Sandbox.

Monitoring Jenkins with Java Melody

Jenkins is a self-contained, open source automation server which can be used to automate all sorts of tasks related to building, testing, and delivering or deploying software.”

Jenkins is written in Java (making it an ideal candidate to be monitored by Instana) and can be extended via plugins. 

There are thousands of plugins, created and maintained by the community, that provide a range of functionality from unit testing, to security, to compliance reporting.

There is a monitoring plugin for Jenkins that provides a lot of data about what’s going on within Jenkins and about the tasks being performed by Jenkins. The Jenkins monitoring plugin relies on JavaMelody which is a basic metric charting tool. 

JavaMelody is an open source application used to monitor Java or Java EE application servers.

It measures and calculates statistical information based on application usage. The resulting data can be viewed in a variety of formats including evolution charts, which track various operations and server attributes over time. 

There are also robust reporting options that allow data to be exported in either HTML of PDF formats.

For Demo, Please refer below video:

WebDriverIO Introduction

Webdriver.io is a mobile and browser test automation framework that has recently become quite popular in the software testing industry. 

This free and open-source framework is written in JavaScript and runs on Node.js. Packaged into npm, WebdriverIO is easy to install and use. This framework enables you to test web applications as well as native mobile apps.

Webdriver is popular because it is backed by Selenium which means you can run test scripts on all browsers. While it brings all the advantages of Selenium, it eliminates the pain of writing Java-based scripts.

 It allows you to easily integrate it with multiple testing frameworks such as Appium to bring the best out of both worlds.

The Key Features of WebDriverIO:

• Run automation tests both for web applications as well as native mobile apps
• Simple and Easy Syntax
• Integrating tests to third-party tools such as Appium.
• ‘Wdio setup wizard’ to make the setup simple and easy.
• Integrated test runner

WebDriverIO Vs Selenium WebDriver

Both WebDriverIO and Selenium WebDriver are open source and are used for browser testing. Selenium is used for automating browsers, while WebDriverIO is used for automating both browsers and native mobile apps.

Prerequisites For Setting Up WebDriverIO

• You need to install NodeJS in your machine before setting up WebDriverIO.
• Additionally, you’ll need to install VSCode IDE
• To install WebDriverIO CLI, execute the below command in the terminal.      npm i --save-dev @wdio/cli

Introduction to WebLogic Scripting Tool

The WebLogic Scripting Tool (WLST) is a command-line scripting interface that the weblogic administrators and operators use to monitor and manage WebLogic Server instances and domains.

It can replace configuration wizard, template builder, command line deployment: weblogic.Deployer, admin console.

WLST is a tool which is based on the Python programming language and uses the Jython feature to act as an administrator interface of the WebLogic Server.

WLST modes

WLST can be used in several modes; we can however group them in the following main three categories:

Offline: Mostly used to create new domains like the configuration domain wizard

Online: Used to perform online administration tasks just like the Administration console

Embedded: Invoked directly from Java code

Sample HelloWorld Program:

import sys

if len(sys.argv) > 1:

    print sys.argv[1]+" from the console" 

else:

    print "Hello World from the script

From Shell:

java weblogic.WLST HelloWorld.py "Hello World"

Time-Based One Time Password

Conventional passwords – however strong the user makes them – have a disadvantage: if somebody else knows the character string, security is no longer guaranteed. One solution would be to change passwords regularly, but even the most exemplary users do not do this every hour. 

The solution is a TOTP.

A time-based one-time password (TOTP) is a temporary passcode generated by an algorithm that uses the current time of day as one of its authentication factors.

Time-based one-time passwords are commonly used for two-factor authentication and have seen growing adoption by cloud application providers.

TOTP is in fact a further development of HOTP, which stands for HMAC-based one-time password. Like HOTP, TOTP is based on the HMAC procedure – the hash operation in the background. Both the user’s device and the server generate a hash value by combining the secret key with a counter. 

The two values are identical, which is how the authentication works.

The hash function itself is not defined; in practice SHA-1 is often used (including by Google Authenticator, for example). SHA-1 generates a 160-bit hash value. For convenience, this value is truncated using a compression function. 

The final result is a short number (six digits for example) which the user can easily use to sign in to the web service.

For the time-based one-time password algorithm, there are three important formulas:

TOTP = HOTP(SecretKey,CurrentTime)

This basic formula simply defines that the TOTP is a HOTP procedure with two parameters – SecretKey and CurrentTime:

SecretKey: Randomly generated password, known to both the server and the client

CurrentTime: Current time in Unix time

However, this time value changes every second, which doesn’t leave the user long enough to enter the generated code. 

In other words, one second later, the TOTP is no longer valid, because the server has already generated a new hash value. A further formula is therefore required:

CurrentTime = floor((unixtime(now) – unixtime(T0))/T1)

The CurrentTime parameter is defined as follows:

unixtime(now): Current time in Unix time

unixtime(T0): Unix time at T0, the point from which the time steps are counted – in most cases midnight on January 1, 1970 (=0)

T1: The period for which the TOTP will be valid (usually 30 seconds)

floor: Rounding function to round the calculated value down to a whole number

Multi-Tenancy in SpringBoot

 Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers. Each customer is called a tenant.

Tenants may be given the ability to customize some parts of the application, such as the color of the user interface (UI) or business rules, but they cannot customize the application’s code.

We can implement multi-tenancy using any of the following approaches:

Database per Tenant: Each Tenant has its own database and is isolated from other tenants.

Shared Database, Shared Schema: All Tenants share a database and tables. 

Every table has a Column with the Tenant Identifier, that shows the owner of the row.

Shared Database, Separate Schema: All Tenants share a database, but have their own database schemas and tables.