Identity 

Management 

and 

Access Control 

in 

Multi-clouds 

TETRATE 

January 23rd-24th, 2020 
Day 2 

Welcome 

7:30 am TETRATE 
 

 

 

Panelist: 

oba

Sec Architecture, 

HSBC 

Panel: 

Experiences – Early Adopters Moderator: (NOTE: This portion will not be webcast) Deepak Jeevankumar, 

Dell Tech Capital 

Panelist: Panelist: Aradhna Chetal, Gl l Head Cloud 

Anil Vatti Lixun Qi, 

8:30 am Chief Architect, Visa Senior Tech Lead,

Freddie Mac 
 

 

 

i

Keynote: 

Cyber Future: 

Evolution, Mutat ons, 

André Mendes 

Chief Information Officer (Acting), Salutations. Oh my! 

DoC 

9:15 am TETRATE 
 

 

 

 

Cyber Future 

Evolution, Mutations, Saltations. Oh my!

André V. Mendes January 24th , 2020 

Chief Information Office (Acting) 

Department of Commerce 
 

 

 

 

 

 

 

About this presentation... 

•Technology evolution mirrors biological

evolution 

• Organizations that fail to adapt.... fail 

•Tech strategy must be driven by likely corollaries

• Unlimited processing, storage and bandwidth

•Cyber Security will become world security

•Ubiquitous virtualization drives requirements

•Wet interfaces/upgrades = ultimate opportunity/

peril 

• For next 30 minutes....abandon what you know today. 

2/3/20 6 
 

 

 

 

 

 

 

 

 

 

4 Billion Years of Biological Evolution 

•Unicellular organisms - Billions of years

• Creation of basic life functions

• Rise of DNA as digital repository (code, execution, result)

•Higher level organisms - Tensofmillionsof years 

• Sophisticated species interaction

•Humanoids - Millions of years

• Societal structures and functional differentiations

•Homo Sapiens Sapiens - Hundreds of thousands of years

• Sentience, Conscience, Ethics, Philosophy, Abstraction

• Much shorter intervals, much bigger leaps 

2/3/20 7 
 

 

 

 

 

 

 

 

Continues in accelerating societal change 

•19th century – More growth than previous 18

• Industrial Revolution, Rise of Democracy

•First 20 years of 20th - Eclipsed all of the 19th

• Sanitation, Expansion of Electricity

•Commercial WWW is about 26 years old

• Facebook, Twitter are teenagers, Instagram is 10

•21st will unleash ±200 centuries of progress

• It is virtually impossible to predict 2099

• Except for this:

• By century’s end standard humans will not be top of heap 

2/3/20 8 
 

 

 

Infinite/”Affordable” Computing Power 

•1997 - ASCI Red

• 1.3 Teraflops (Trillion Flops)

•2015 - Intel’s “Knight’s Landing”

• 8 Teraflops

•2021 – DOE/INTEL/Cray – 

Aurora

• 1 EXAflop (Quintillion)

• 1,000,000,000,000,000,000 Flops

•2099 – Unknown entity, name

•Unthinkable, distributed capacity 

2/3/20 9 
 

 

 

 

Infinite/”Affordable” Storage 

•2002 IBM Shark SAN

•1.3 Terabyte!

•Large Freezer Size

•2016 Hitachi Desktar

•4 Terabytes

•Cell phone Size

•2018 SanDisk Micro SD

Card

•1 Terabyte

•Fingernail size 
 

 

Massive Bandwidth Expansion 

• How long to download an HD Movie?

• 2001 – 3G Cellular – 384 Kbps – 26 Hours

• 2009 – 4 G Cellular – 100 Mbps – 6 Minutes

• 2020 – 5 G Cellular – 10 Gbps – 3.6 seconds

• 2099 – ? – Immediate access to everything 

2/3/20 11 
Ruthless paradigms! 

bandwidth storage 

MIPS 

10

X 

1X 

1,000x 

100X 

10,000,000x 

1,000,000x 

100,000x 

10,000x 

1970 1980 1990 2000 2010 2020 

2/3/20 12 
 

 

Imagine a future where... 

•Unlimited Computing Power

•Unlimited Storage

•Unlimited Metadata

•Unlimited Indexing

•Unlimited Bandwidth

•Feed a chip directly into your

imagination 

2/3/20 13 
 

 

Back to evolution... 

• Not different from Darwinian Evolution

• Except directed and accelerated

• With ever faster processors

• Betters sensors

• Exposed to ever more complex ethical 

issues

• Susceptible to “infection” 

2/3/20 14 
 

 

 

 

 

 

 

The Century of AI 

• Every decade since the 70’s wasthe AI Decade

• TechnologicalPresbyopia 

•Overestimate short term

•Underestimate long term

• This isthe AI Century (to 2035)

• AI will decide what to call itself after that

• My guess...”artificial” will not be a part of it

• Reached the crucial threshold of productive self-learning 

2/3/20 15 
 

 

 

 

 

 

 

 

 

Inexorable corollary 

•Just like it evolved in carbon-based lifeforms:

• Sentiency in Silicon-based systems a given

•Just as “values” have evolved in mankind:

• We must infuse “Values” in every AI algorithm

•Just as “values” are routinely ignored in 

humankind:

• “Values” will be ignored in rogue AI

•Are we AI?

•What is the difference? 

• Without upgrades.... 

• Vastly inferior in processing, storage & 

bandwidth 2/3/20 16 
 

 

 

 

Juggernaut? 

•Massive opportunity for progress

• Universal process optimization

• Faster/cheaper services to citizens

• Law enforcement, basic medicine, 

teaching

• Self service everything

• Accelerating progress in every field

• Accelerating acceleration

•Literally creating a Science Fiction future 

2/3/20 17 
 

 

 

 

 

 

 

 

Or Tsunami? 

•Not happening in a vacuum

• Manufacturing globalization/Nationalism tensions

• Technologyubiquity including global access 

• Massive displacement of lower skill employment

• Substantial impact on low/mid level white collar

employment

• Potential unimaginable cultural disruption

• Potential unthinkable wealth gaps(with UI

denominators)

• Potential for major geo-political upheaval

•Evolution’s rarely been easy, fair, 

considerate... 

2/3/20 18 
 

 

 

 

 ve today!

What about Homo Sapiens Sapiens? 

•Significant life expectancy increases

• Genomics, Proteomics, Nanotech

•Biologics and Immunotherapy

•Genomic optimizations

• Pre-implantation (Fanconi’s Anemia)

• CRSPER

• Capability enhancement

•Dramatic increases in “upgrades”

• Wet interfaces with sensors/robotics

• Memory implants, “Net” Interfaces

•The first immortal human being is

ali 

2/3/20 19 
 

 

 

What about Cyber? 

• If you think the stakes are high today.... 

• IOT

• End-to-End Automation

• Artificial Intelligence

• Human Interfaces/

Upgrades 

• Today’s challengestomorrow’s Child’s Play

• How do we survive/thrive? 

2/3/20 20 
 

 

 

 

 

 

 

 

 

How do we survive the onslaught! 

• Implement proven evolutionary lessons

• Standardize and modularize everything

• Create abstraction layers for commodity functions

• Focus on positive “mutations” at the “value” layer

• You cannot afford to “own”, “maintain”, “operate” the entire stack

• Security becomes the first development requirement

• Not last check before deployment, not a funding afterthought, Day 1

ATO

• Establish authoritative Identification

• Tokens, PIV, Biometrics, MFA is a must

• Zero Trust environment with complete geographic abstraction

• Lowest denominator permissions with temporary elevation

• Establish common operating patterns to spot deviations 

2/3/20 21 
 

 

 

 

 

 

 

 

 

 

There are no significant saltations! 

•Not in the biological realm, not in the cyber realm

• Most issues are preventable, avoidable, manageable

• Highest profile problems are self inflicted

•Operational discipline – USAGM, OPM, Equifax

•Insider threats – Manning, Snowden, Wikileaks

• Supply chain – Target(POS),Huawei? 

• Phishing – Podesta and millions of other users

• Yetsomuch energy is pursuing exoteric targets 

• Focus on the fundamentals, everything else will follow

• Boring is the new fun! 

2/3/20 22 
Discussion 
 

Coffee Break 

Back @ 10:15 AM 

10:00 am TETRATE 
 

 

 

 

 

Anil Karmel 

President, Cloud Security Alliance 

DC Metro Area Chapter 

CEO, C2 Labs 

10:15 am 

We All Live in a 

Yellow Submarine 

(Multi-cloud World): 

DevSecOps 

Challenges and Best 

Practices 

TETRATE 
 

 

 

 

 

 

Anil Karmel 

Co-Founder and CEO, C2 Labs 

Co-Chair, CSA Application Containers and 

We all live in a Yellow 

Submarine 

(Multi-Cloud World) 

DevSecOps Challenges and 

Best Practices 

Microservices Working Group 

President, CSA DC Chapter 

akarmel@c2labs.com 

© c2labs.com 
 

Definitions 

Microservices and Containers 

• Microservices 

– Decompose Complex Applications into Small, Independent Processes communicating 

with each other using language-agnostic API’s 

– Highly Decoupled and Modular with services organized around capabilities (e.g. User 

Interface, Billing) 

• Containers 

– Much like Virtualization abstracts the Operating System from Hardware, Containers 

abstracts Applications from the Operating System 

– Applications are isolated from other Applications on the same Operating System 

– Allows for Cloud Portability and Scale Up/Out 

– Security issues need to be evaluated and addressed in native container deployments 

© c2labs.com 
 

NIST and CSA Partnership 

Researching Together to develop Best Practices 

• NIST and CSA joined forces to define best practices for Application 

Containers and Microservices (ACM) 

– CSA ACM Members joined the NIST ACM Cloud Security Working Group 

– NIST artifacts served as the foundation for CSA ACM work 

– NIST SP 800-180: NIST Definition of Microservices, Application Containers and 

System Virtual Machines 

– NIST SP 800-190: Application Container Security Guide 

– NIST SP 800-160: Systems Security Engineering: Considerations for a 

Multidisciplinary Approach in the Engineering of Trustworthy Security Systems 

– NIST IR DRAFT: Challenges in Securing Application Containers and Microservices 

– NIST SP DRAFT: Best Practices in Securing Application Containers and Microservices 

© c2labs.com 
 

 

 

 

 

 

CSA Application Container and Microservices (ACM) 

Charter 

CSA ACM Working Group Charter 

• Objectives – Q1 2020 

– Best Practices to Implement a Secure Microservices Architecture 

– Microservices secure development guidance and governance 

– Best Practices for implementing a Microservices Architecture for Cloudnative applications 

– Best Practices for decomposing monolithic applications into Microservices 

© c2labs.com 
 

 

 

 

CSA Application Container and Microservices (ACM) 

Publications 

Click on Titles to 

download the 

publications 

Slide 30 

Best Practices for Implementing a 

Secure Application Container 

Architecture 

Challenges in Securing Application 

Containers and Microservices 

© c2labs.com 
 

 

 

 

 

 

 

 

Container Security 

Challenges 

• Increased Attack Surface 

– Containers are far more complex than VM’s wherein a single Application can consist of 

1000’s of microservices 

– Underlying Linux Operating System complexities can be exploited by attackers to 

compromise all containers on a host OS 

– Runtime Compromise / Vulnerabilities / Misconfiguration 

• Secure Software Development 

– Containers can have code pushed to them from untrusted sources 

• Log Management 

– Big Data Problem: How do you view and manage logs across 1000’s of containers 

• Orchestration 

– Infrastructure now runs as code (Puppet/Chef/Ansible) 

– Software developers, not infrastructure staff now run the data center 

© c2labs.com 
 

 

 

 

 

Container Security 

Challenges 

• File System Compromise 

– Microservices in the Application Container could be compromised by an attacker 

• Networking 

– A compromised container could result in lateral movement 

• Run Time Compromise / Privilege Escalation 

– An attacker could modify a microservice in an Application Container which compromises 

the application or container itself 

© c2labs.com 
 

 

 

 

 

 

 

 

Container Security 

Solutions 

• Increased Attack Surface 

– Employ MicroVM’s (Just Enough VM) 

– Monitor Containers at Runtime / Real-time scan for Vulnerabilities and Misconfiguration 

and Remediate 

• Secure Software Development 

– Whitelist/Blacklist Containers 

– Establish a secure container registry 

– Sign containers and code (MD5) 

– “Shift-left” vulnerability and bug scanning before deployment 

• Log Management 

– Centralize container logs including developer actions 

• Orchestration 

– Employ orchestration platform to manage containers across environments 

(DEV,TEST,QA,PROD) and across clouds 

© c2labs.com 
 

 

 

 

 

 

 

Container Security 

Solutions 

• File System Compromise 

– Ensure file system is read only 

– Treat infrastructure as stateless, ideally serverless 

• Networking 

– Ensure application containers can only talk to other approved application containers 

– Leverage Namespaces and SDN in orchestration tools 

• Run Time Compromise / Privilege Escalation 

– Set filter on Linux Kernel to prevent privilege escalation and implement white lists 

– Anomaly detection based on a deviation from a known baseline to prevent remote code 

execution 

© c2labs.com 
 

 

 

 

 

 

 

 

 

Slide 35 

Microservices Security 

Challenges and Solutions 

• Decomposition of Applications 

– Need to decompose applications into microservices correctly, so they only do 

one thing well, driving development of secure code 

– Monolithic code with 1,000 DLLs needs to be decomposed into 1,000 

microservices which makes it more secure and maintainable 

• Interface-driven development 

– Need to have well defined REST API’s to ensure microservices talk consistently 

to each other 

– Authentication of API’s should leverage OAuth and other secure protocols 

© c2labs.com 
Real World Examples 

© c2labs.com Slide 36 
 

 

 

 

Docker CI/CD Pipeline Overview w/ GitLab 

Development Version Control & Continuous Integration Continuous Deployment 

Code Pull/Push 

Docker Trusted 

CI/CD Pipeline Repository (.gitlab-ci.yml) 

GitLab Runners 

Test Scripts 

Image Build 

Image Sign/Push 

Stack Deploy 

© c2labs.com Linux Windows 

Image Push 

Deploy Stack 

Slide 37 

Docker Universal 

Control Plane 
 

 

 

 

 

 

GitLab: What are Runners? 

• Runners are the fundamental component of a CI/CD pipeline 

• Runners are isolated virtual machines that run predefined steps through the GitLab CI API 

– Steps are defined in a .gitlab-ci.yml file 

– Steps execute as jobs, jobs are grouped together by stages, and stages are grouped together by 

pipelines 

– Job execution occurs on the Runner machine 

– Any dependencies/enablers that are required for a job to execute must be installed on the Runner 

machine pipeline 

stage 

job 

© c2labs.com Slide 38 
Docker CI/CD Pipeline Stages - Customizable 

Development Pipeline 

Production Pipeline 

Build Clean Deploy 

Build Dev Deploy Dev 

Build ProdA 

Build ProdB 

Clean 

Deploy ProdA OR 

© c2labs.com Slide 39 

Deploy ProdB 
 

 

 

 

 

 

 

 

 

 

 

 

GitLab On-Premise 

CI/CD Pipeline 

• Example of a production 

GitLab CI/CD pipeline 

• All customizable; can 

implement your design easily 

• (CI) Built and pushed image 

in DEV and both production 

environments 

• (CI) Performed a clean build 

• (CD) Deployed to DEV and 

the chosen production 

environment 

• (CD) DEV deploy is triggered 

by commit to dev or master

branch 

• (CD) PROD deploy is 

triggered via a Tag and a 

Manual start by user with the 

right permissions 

© c2labs.com Slide 40 
 

 

 

 

 

 

 

 

 

 

 

 

 

Slide 41

Commercial Tool 

Build Pipeline 

• CI/CD triggered based off of 

protected branch strategy 

• CI steps generally deploy on a 

Pull Request (PR) 

• CD steps generally deploy after 

approving the PR 

• Testing, documentation, 

database upgrades, security 

scanning, logging, and 

Kubernetes deployment are done 

from the Feature branch -> DEV 

-> QA -> PROD with no manual 

labor; unlocking our developers 

full potential 

• Governance is employed by 

adding workflow approvals to PRs 

• All logs are maintained in Azure 

DevOps for Configuration 

Management 

© c2labs.com 
 

 

 

 

 

 

 

 

Multi-Stage 

Pipeline 

• Container is built and 

pushed to our private Azure 

Registry 

• Security scans are done via 

NPM Audit and Anchore 

• Source code scan is done by 

SonarQube – pass/fail logic 

is coded into the stages 

• Artifacts are stored for 

troubleshooting or later 

forensics if a defect escapes 

© c2labs.com Slide 42 
 

 

 

 

 

 

 

GitHub Integration 

• Leveraged 

webhooks/plugins to show 

pipeline progress in the 

GitHub PR 

• Details link to Azure DevOps 

to view artifacts and raw 

logs 

• Governance enforces code 

reviews, pipeline checks 

passing, and two-person 

rule for a manager to 

approve code changes into a 

protected branch 

© c2labs.com Slide 43 
 

 

 

 

 

 

 

 

 

Integration with 

Azure DevOps 

• Details pulled into GitHub 

and stored with the PR 

• History maintained over 

time for full configuration 

management traceability 

• Builds and deploys are 

tagged with the commit 

number to allow for easy 

rollbacks in Kubernetes 

© c2labs.com Slide 44 
 

 

 

 

 

 

 

 

 

 

 

Slide 45 

Azure DevOps 

Pipelines 

• Multiple pipelines 

configured that are 

triggered based on GitHub 

branching logic 

• Each pipeline has one or 

more stages to the job 

• Each stage has one or 

more tasks that execute 

• Pipeline configurations are 

developed in source code 

and under configuration 

management in GitHub 

• NOTE: Pipeline changes 

are tested in a separate 

cloned project prior to 

being introduced into the 

Production pipeline 

© c2labs.com 
 

 

 

 

 

 

 

 

 

Definitions 

Microservices and Containers 

• Microservices 

– Decompose Complex Applications into Small, Independent Processes communicating 

with each other using language-agnostic API’s 

– Highly Decoupled and Modular with services organized around capabilities (e.g. User 

Interface, Billing) 

• Containers 

– Much like Virtualization abstracts the Operating System from Hardware, Containers 

abstracts Applications from the Operating System 

– Applications are isolated from other Applications on the same Operating System 

– Allows for Cloud Portability and Scale Up/Out 

– Security issues need to be evaluated and addressed in native container deployments 

© c2labs.com 
 

 

 

 

 

 

 

 

NIST and CSA Partnership 

Researching Together to develop Best Practices 

• NIST and CSA joined forces to define best practices for Application 

Containers and Microservices (ACM) 

– CSA ACM Members joined the NIST ACM Cloud Security Working Group 

– NIST artifacts served as the foundation for CSA ACM work 

– NIST SP 800-180: NIST Definition of Microservices, Application Containers and 

System Virtual Machines 

– NIST SP 800-190: Application Container Security Guide 

– NIST SP 800-160: Systems Security Engineering: Considerations for a 

Multidisciplinary Approach in the Engineering of Trustworthy Security Systems 

– NIST IR DRAFT: Challenges in Securing Application Containers and Microservices 

– NIST SP DRAFT: Best Practices in Securing Application Containers and Microservices 

© c2labs.com 
 

 

 

 

 

 

CSA Application Container and Microservices (ACM) 

Charter 

CSA ACM Working Group Charter 

• Objectives – Q1 2020 

– Best Practices to Implement a Secure Microservices Architecture 

– Microservices secure development guidance and governance 

– Best Practices for implementing a Microservices Architecture for Cloudnative applications 

– Best Practices for decomposing monolithic applications into Microservices 

© c2labs.com 
 

 

 

 

CSA Application Container and Microservices (ACM) 

Publications 

Click on Titles to 

download the 

publications 

Slide 49 

Best Practices for Implementing a 

Secure Application Container 

Architecture 

Challenges in Securing Application 

Containers and Microservices 

© c2labs.com 
 

 

 

 

 

 

 

 

Container Security 

Challenges 

• Increased Attack Surface 

– Containers are far more complex than VM’s wherein a single Application can consist of 

1000’s of microservices 

– Underlying Linux Operating System complexities can be exploited by attackers to 

compromise all containers on a host OS 

– Runtime Compromise / Vulnerabilities / Misconfiguration 

• Secure Software Development 

– Containers can have code pushed to them from untrusted sources 

• Log Management 

– Big Data Problem: How do you view and manage logs across 1000’s of containers 

• Orchestration 

– Infrastructure now runs as code (Puppet/Chef/Ansible) 

– Software developers, not infrastructure staff now run the data center 

© c2labs.com 
 

 

 

 

 

Container Security 

Challenges 

• File System Compromise 

– Microservices in the Application Container could be compromised by an attacker 

• Networking 

– A compromised container could result in lateral movement 

• Run Time Compromise / Privilege Escalation 

– An attacker could modify a microservice in an Application Container which compromises 

the application or container itself 

© c2labs.com 
 

 

 

 

 

 

 

 

Container Security 

Solutions 

• Increased Attack Surface 

– Employ MicroVM’s (Just Enough VM) 

– Monitor Containers at Runtime / Real-time scan for Vulnerabilities and Misconfiguration 

and Remediate 

• Secure Software Development 

– Whitelist/Blacklist Containers 

– Establish a secure container registry 

– Sign containers and code (MD5) 

– “Shift-left” vulnerability and bug scanning before deployment 

• Log Management 

– Centralize container logs including developer actions 

• Orchestration 

– Employ orchestration platform to manage containers across environments 

(DEV,TEST,QA,PROD) and across clouds 

© c2labs.com 
 

 

 

 

 

 

 

Container Security 

Solutions 

• File System Compromise 

– Ensure file system is read only 

– Treat infrastructure as stateless, ideally serverless 

• Networking 

– Ensure application containers can only talk to other approved application containers 

– Leverage Namespaces and SDN in orchestration tools 

• Run Time Compromise / Privilege Escalation 

– Set filter on Linux Kernel to prevent privilege escalation and implement white lists 

– Anomaly detection based on a deviation from a known baseline to prevent remote code 

execution 

© c2labs.com 
 

 

 

 

 

 

 

 

 

Slide 54 

Microservices Security 

Challenges and Solutions 

• Decomposition of Applications 

– Need to decompose applications into microservices correctly, so they only do 

one thing well, driving development of secure code 

– Monolithic code with 1,000 DLLs needs to be decomposed into 1,000 

microservices which makes it more secure and maintainable 

• Interface-driven development 

– Need to have well defined REST API’s to ensure microservices talk consistently 

to each other 

– Authentication of API’s should leverage OAuth and other secure protocols 

© c2labs.com 
Real World Examples 

© c2labs.com Slide 55 
 

 

 

 

Docker CI/CD Pipeline Overview w/ GitLab 

Development Version Control & Continuous Integration Continuous Deployment 

Code Pull/Push 

Docker Trusted 

CI/CD Pipeline Repository (.gitlab-ci.yml) 

GitLab Runners 

Test Scripts 

Image Build 

Image Sign/Push 

Stack Deploy 

© c2labs.com Linux Windows 

Image Push 

Deploy Stack 

Slide 56 

Docker Universal 

Control Plane 
 

 

 

 

 

 

GitLab: What are Runners? 

• Runners are the fundamental component of a CI/CD pipeline 

• Runners are isolated virtual machines that run predefined steps through the GitLab CI API 

– Steps are defined in a .gitlab-ci.yml file 

– Steps execute as jobs, jobs are grouped together by stages, and stages are grouped together by 

pipelines 

– Job execution occurs on the Runner machine 

– Any dependencies/enablers that are required for a job to execute must be installed on the Runner 

machine pipeline 

stage 

job 

© c2labs.com Slide 57 
Docker CI/CD Pipeline Stages - Customizable 

Development Pipeline 

Production Pipeline 

Build Clean Deploy 

Build Dev Deploy Dev 

Build ProdA 

Build ProdB 

Clean 

Deploy ProdA OR 

© c2labs.com Slide 58 

Deploy ProdB 
 

 

 

 

 

 

 

 

 

 

 

 

GitLab On-Premise 

CI/CD Pipeline 

• Example of a production 

GitLab CI/CD pipeline 

• All customizable; can 

implement your design easily 

• (CI) Built and pushed image 

in DEV and both production 

environments 

• (CI) Performed a clean build 

• (CD) Deployed to DEV and 

the chosen production 

environment 

• (CD) DEV deploy is triggered 

by commit to dev or master

branch 

• (CD) PROD deploy is 

triggered via a Tag and a 

Manual start by user with the 

right permissions 

© c2labs.com Slide 59 
 

 

 

 

 

 

 

 

 

 

 

 

 

Slide 60

Commercial Tool 

Build Pipeline 

• CI/CD triggered based off of 

protected branch strategy 

• CI steps generally deploy on a 

Pull Request (PR) 

• CD steps generally deploy after 

approving the PR 

• Testing, documentation, 

database upgrades, security 

scanning, logging, and 

Kubernetes deployment are done 

from the Feature branch -> DEV 

-> QA -> PROD with no manual 

labor; unlocking our developers 

full potential 

• Governance is employed by 

adding workflow approvals to PRs 

• All logs are maintained in Azure 

DevOps for Configuration 

Management 

© c2labs.com 
 

 

 

 

 

 

 

 

Multi-Stage 

Pipeline 

• Container is built and 

pushed to our private Azure 

Registry 

• Security scans are done via 

NPM Audit and Anchore 

• Source code scan is done by 

SonarQube – pass/fail logic 

is coded into the stages 

• Artifacts are stored for 

troubleshooting or later 

forensics if a defect escapes 

© c2labs.com Slide 61 
 

 

 

 

 

 

 

GitHub Integration 

• Leveraged 

webhooks/plugins to show 

pipeline progress in the 

GitHub PR 

• Details link to Azure DevOps 

to view artifacts and raw 

logs 

• Governance enforces code 

reviews, pipeline checks 

passing, and two-person 

rule for a manager to 

approve code changes into a 

protected branch 

© c2labs.com Slide 62 
 

 

 

 

 

 

 

 

 

Integration with 

Azure DevOps 

• Details pulled into GitHub 

and stored with the PR 

• History maintained over 

time for full configuration 

management traceability 

• Builds and deploys are 

tagged with the commit 

number to allow for easy 

rollbacks in Kubernetes 

© c2labs.com Slide 63 
© c2labs.com Slide 64

Azure DevOps 

Pipelines • Multiple pipelines 

configured that are 

triggered based on GitHub 

branching logic

• Each pipeline has one or 

more stages to the job

• Each stage has one or 

more tasks that execute

• Pipeline configurations are 

developed in source code 

and under configuration 

management in GitHub

• NOTE: Pipeline changes 

are tested in a separate 

cloned project prior to 

being introduced into the 

Production pipeline
Cloud Smart, 

Application 

Rationalization, and 

ICAM

TETRATE

Stephen Naumann

Senior Advisor – Data Center 

Practitioner 

GSA

10:45 am
Office of Government-wide Policy

GSA OGP

DCOI, Cloud Smart, & ICAM

Steve Naumann, Senior Advisor | January 2020
G S A O F F I C E O F G O V E R N M E N T - W I D E P O L I C Y 

Overview

Data Center and Cloud Optimization Initiative PMO

Data Center 

Optimization Initiative 

Closure & 

Consolidation

Optimization

Cloud Smart

Workforce

Security

Procurement

Application 

Rationalization 

Review; Reward; 

Refresh; Remove
G S A O F F I C E O F G O V E R N M E N T - W I D E P O L I C Y 

Application Rationalization

ICAM

ICAM

ICAM

ICAM

Ap

p.

X

ICAM

ICAM

ICAM

ICAM

Ap

p.

Z

ICAM

ICAM

ICAM

ICAM

Ap

p.

Y ICAM

ICAM

ICAM

Ap

p.

X

ICAM

APPLICATION PORTFOLIO APPLICATION PORTFOLIO

● What is Application Rationalization?

● How is it connected to ICAM?

RATIONALIZATION
G S A O F F I C E O F G O V E R N M E N T - W I D E P O L I C Y 

● SLAs for access to log 

data

● Governance model 

aligned to ICAM 

systems

Cloud Policy Landscape

Implications for ICAM

● TIC 3.0

● Zero Trust Networks

● The Internet of Things

Cloud Smart Strategy 

encourages: 

Other policies and 

paradigms: 
G S A O F F I C E O F G O V E R N M E N T - W I D E P O L I C Y 

Recommended Process:

● Assess enterprise capabilities

○ Federation?

○ Fault tolerant? 

○ Secure? 

● Perform an ICAM gap analysis

● Address gaps (buy new or modify existing)

Cloud Adoption & ICAM

Challenges of Moving to Cloud
G S A O F F I C E O F G O V E R N M E N T - W I D E P O L I C Y 

Goals in Common
Questions? 

Email dccoi@gsa.gov
Questions

(Slido)

VIRTUAL AUDIENCE

11:15 pm TETRATE
Ad-Hoc Panel: 

What is in Your Mind When You 

Think ZTA & DevSecOps

Moderator 1:

Jeyappragash Jeyakeerth

Co-Founder, 

Tetrate

Panelist 1

Panelist2 Panelist3 

Panelist4 

Moderator 2:

Michaela Iorga

Senior Security Technical Lead, 

NIST

This is an ad-hoc panel and the 

panelists will be selected randomly from 

the members of the audience that 

expressed interest in participating in this 

dialog by registering in advance. 

11:30 am
Day 2 

Closing Remarks 

and Adjourn 

5:00 pm TETRATE