Friday, January 20, 2017

A Chrome Plugin: IsItUp serverless service dashboard

A coworker created a Chrome Extension that acts as a zero-infrastructure dashboard. It provides a simple home page that displays service health and support or documentation links related to that service.  The plugin reads JSON file/text to make service calls and build the dashboard. The following picture shows 5 services across up to 6 environments.  The top service does not have a Production environment. The bottom service represents a 3rd external service that has one test environment and one production environment.


The IsItUp chrome executes health checks via HTTP/HTTPS calls.  The extension requires connectivity to the services being monitored.

Video Walk-through

The video explains various cell examples and describes how the extension might be used. The plugin used for the video was downloaded from the Chrome Web Store .

Video created with version available Jan 21 2017

Cell Explanation

Each cell contains one Service Status plus any number of supporting links.  All link icons open up a new tab to the appropriate supporting web page. It could be documentation, log aggregation, real operations consoles, dashboards or something else.  The "reload" icon will refresh the service status by re-calling the service.

The image to the right represents a service deployed in AWS. It shows a healthy service status along with a chrome link and an AWS console link.

This example represents a service deployed in a development environment. The supporting icons link to swagger documentation, Jenkins, Sonar, a Confluence wiki and the GitHub repository for this service.

Cells in the top row represent the fact the service doesn't exist in that environment.

Cells in the bottom row represent the same application deployed in two different cloud environments. Each contains a link to some web site plus a link to the appropriate cloud console for that environment.

Basic Configuration 

IsItUp has an options panel that accepts JSON based configuration.  The extension comes with the sample file used in the video and these screen shots. The sample configuration can be extracted from the Configuration Text box on the options page. The sample will change over time as new features are added or as users make suggestions.

The file has two main sections, header information and site specifications. You can find the sample JSON containing these sections on the options screen.

Header Section

The header contains a description of this dashboard in "title", row header names and column header names. The extension validates the number of row headers matches the number of rows. It also validates that the number of column headers matches the number of columns.

  {
  "title": "Demonstration Status",
  "headers": {
    "cols": "dev/ci,integration,func test,qa,prod azure,prod aws",
    "rows": "Web App 1,Web App 2,Service 1,Service 2,External Service"
  },

Site Specification Section

A single cell contains a "healthUrl" and zero-N "other" links and corresponding icons.  This sample shows a healthUrl plus two additional links. One is a link to this Chrome extension's GIT repository. The other link is to the AWS console. This could have been to a deeper link like some CloudWatch dashboard.

  {
    "healthUrl": "http://headers.jsontest.com/",
    "other": [
      {
        "url": "https://chrome.google.com/webstore/search/isitup%20naveen?hl=en",
        "icon": "https://www.google.com/s2/favicons?domain=chrome.google.com"
      },
      {
        "url": "https://aws.amazon.com/console/",
        "icon": "https://www.google.com/s2/favicons?domain=aws.amazon.com"
      }
    ]
  }

Plugin Source
Plugin source code is located on GitHub https://github.com/NaveenGurram/IsItUp


Created 2017 Jan 20

Sunday, January 15, 2017

A Chrome Plugin: Highlighting your AWS Account

I'm working on a set of projects based in AWS. Our projects have somewhere between 7 and 9 different environments representing different levels of software maturity.  Production is the most restricted.  Development is the least restricted.  The rest fall somewhere in between.

The company partitions the different levels of their SDLC into separate AWS accounts. Each account can have multiple environments that are of similar concerns and access controls.

AWS account isolation makes it easy to identify and implement security rules and vary developer , dev-ops and operations access based on the account.

The diagram at right shows a typical 3 account set-up where some of the accounts contain multiple environments. Our company actually has over 20 accounts used for various pre-prod, prod and partner purposes


The AWS Console.

The AWS console lets a user operate in a single account at one time.  Enterprise users log into the AWS console with Federated User ids that can provide access to some portion of that Enterprise's accounts. The console displays the AWS Account Alias and some permission and user id information at the top of the screen.  It can be tedious to read that inform
ation when switching between AWS accounts in a short period of time.

A Chrome Extension

One of the developers on my team wrote a Chrome Plugin that highlights  he AWS account information. The plugin provides bassic account information for non-federated accounts like personal or standalone accounts. It optionally color codes a banner at the top of the screen based on some very simple rules related to Account (alias) names.   You can find this plugin 
Try it out or check out the source code.

Samples

Standalone Account

Non federated accounts are all treated the same.

Federated Accounts

With PROD in the AWS account name in any case / capitalization

With QA  or QC in the Aws account name in any case or capitalization


Any other Account name string.





Wednesday, January 4, 2017

Protecting Data in Transit: Trust Chains

Web traffic is protected in-flight when it is transferred via TLS encrypted links using HTTPS.  HTTPS is a protocol that is based on encryption algorithms using asymmetrical keys.  Asymmetrical keys are managed, packaged and distributed via certificates.

Browsers, applications and servers trust certificates and their associated encryption keys based on their trust of the issuing parties known as Certificate Authorities (CA). Public web sites are identified by public/private certificates pairs that are purchased from one of the well known CAs. Their certificate pairs contain an identity component signed by the Certificate Authority and an encryption key that is encrypted by the CA.

  • Server identity is encrypted in the server certificate with the Certificate Authority public key. 
  • Server traffic is encrypted by the server using the private encryption key embedded in the Server's private certificate.  
  • Server traffic is decrypted by clients using the public encryption key embedded the server's public certificate.



Certificates are used to validate server identity and encrypt payloads so that clients can trust the source and content of data they receive. All of this depends on the ability of certificates to securely represent their intended parties.

Public Trust Chains

This trust is implemented via trust chains of Root Certificate Authorities and their child Intermediate Certificate Authorities.

Programs trust certificates signed by CAs in their CA trust list. Public CAs are well known by virtue of the fact that the their root and intermediate Certificate Signing Authority certificates come pre-installed in browsers, applications and some operating systems.


Well known Certificate Authorities charge fees for their certificates. Fees are based on the certificate expiration date, the number of Subject Alternate Names included in the certificate, any wild card status and various other factors. Companies save costs by using these expensive certificates only at the edges of their organizations where 3rd party trust is important.

Corporate Trust Chains 

Certificate authorities are just programs that issue certificates signed using the CA's certificate. This means that companies can issue their own certificates using an internal CA. Corporations can then issue as many certificates as they wish for internal traffic without paying fees to the well known CAs.

Corporate issued certificates are trusted inside their infrastructure if their internal CAs public certificate is installed in corporate browsers and operating systems certificate authority trust stores. This is one of the reasons large corporations automatically install their corporate standard browsers.

Browsers and programs can base trust on any number of corporate and public CAs as long as their Root Certificates are installed in the trust stores.

Self Signing

Certificates can be issued by anyone that can create a Certificate Authority root cert.  Anyone can create a CA root certificate to create their own signing authority. This tends to be of limited use since no one will trust these self-signed certificates since they don't trust the root certificate.

Self-signed certificates can be useful in a development environment because they can be used for on-box testing.  Developers can create a local signing certificate that is used for local server certificates. They can then install the local  signing certificate in their O/S and application trust stores. This lets the developer issue as many certificates as they want for local testing.


Self-signed  certificates can be useful for link encryption where host validation and repudiation is not an issue. This is often useful in a Cloud environment where all link traffic must be encrypted and where hosts are repeatedly created or destroyed as in auto-scale environments.

AWS, for example, uses trusted certificates on ELBs while using self signed certificates between the ASG hosts and the ELB.  The ELB is configured to trust all certificates on the load balanced servers. This means the server HTTPS certificates can be self signed by the individual servers.


Self-signed  certificates can be useful for private communication between servers in a pool.  You see this in cloud environments with clustered products that that have some kind of internal communication bus.

The same self-signing certificate can be installed on each pool server. That same certificate is used to create the back-side bus encrypted link certificates. Each pool server will trust the pseudo-self-signed connections from the other pool servers because they all have the same self-singing root cert.

Trust chains are not required where certificates are only used for encryption and where host validation and repudiation is disabled. Most application platforms automatically do host and certificate validation. Validation must be explicitly disabled if trust validation is to be disabled.

Federated Trust

<to be written later>


Related Topics

  1. Protecting Hybrid Environments: Blog not yet written - Video
  2. Enrypton Basics: Blog - Video
  3. Trust Chains: Blog Video