Using Tetration for Application Security and Policy Enforcement

Protecting assets requires a Defense in Depth approach

Protecting assets within the enterprise requires the network manager to adopt automated methods of implementing policy on endpoints. A defense in depth approach, applying a consistent policy to the traditional firewall as well as policy enforcement on the host, takes a systemic view of the network.

Value added resellers are increasingly helping customers deploy solutions comprised of vendor hardware and software, support for open source software, and developing code which integrates these components. A great example of this, and the subject of this blog, is World Wide Technology making its integration with Ansible Tower and Cisco Tetration available as open source through Cisco DevNet Code Exchange.

I started my career in programming and analysis and systems administration, transitioned to network engineering, and now the projects I find most interesting require a combination of all those skills. Network engineers must view the network in a much broader scope, a software system that generates telemetry, analyzes it, and uses automation to implement policy to secure applications and endpoints.

The theme for Networkers/CiscoLive 1995 was ‘Any to Any.’ However, we don’t live in that world today. Then, the focus was to enable communication between nodes. Today, the focus is to enable network segmentation, restricting communication between nodes for legitimate business purposes. Today we ask, “What’s on my network?” “What is it doing?” and “Should it be?”

A Zero Trust security model, in the data center and on the endpoint, is a common topic for discussion for our customers. The traditional perimeter security model is less effective as cyber security attacks simply bypass firewalls and attack internal assets with phishing exploits. The Tetration Network Policy Publisher is one means to automate policy creation.

Tetration Network Policy Publisher

Introduced in April 2018, the Tetration Network Policy Publisher is an advanced feature enabling third parties to subscribe to the same policy applied to servers by the Tetration enforcement agent.

The Tetration cluster runs a Kafka instance and publishes the enforcement policies to a message bus. Unlike other message bus technologies, Kafka clients explicitly ‘ask’ for messages, by subscribing to a Kafka topic. Access to the policy is provided by downloading the Kafka client certificates from the Tetration user interface.

The enforcement policy messages are encoded as Google Protocol Buffers (protobuf), an efficient and extensible format for exchanging structured data between hosts. While more complex for the programmer, protobufs are both efficient on the wire and CPU compared to JSON or XML.
This feature enables ‘defense in depth’. The enforcement policy can be converted to the appropriate network appliance configuration and implemented on firewalls, router access lists, and security enabled load balancers. Ansible is one means to automate pushing policy to network assets.

Ansible Tower by Red Hat

Ansible Tower is a web-based solution which makes Ansible Engine easier to use across teams within an IT enterprise. Tower includes a REST API and CLI for ease of integration with existing tools and processes. Ansible Engine is built on the open source Ansible project. Red Hat licenses and provides support services for Ansible Tower and Engine.

Ansible has evolved into the defacto automation solution for configuration management across a wide range of compute, storage, network, firewall and load balancer resources in the cloud and on-premise.

Ansible interface to Cisco Tetration Network Policy Publisher

This project provides an abstraction layer between the Tetration Network Policy Publisher and Ansible, allowing the network administrator to push enforcement policy to ‘all the things’, without directly accessing the Tetration Kafka message bus. The code is open source and is publicly available through Cisco DevNet Code Exchange, a curated set of repos that make it easy to discover and use code related to Cisco technologies. The project repository, ansible-tetration, includes an Ansible module that retrieves enforcement policy from Tetration and exposes it as variables to an Ansible playbook. Subsequent tasks within the playbook can apply the policy to the configuration of network devices.

This functionality provides value to network operations as policy is published periodically, in an easily consumed format. NetDevOps engineers can focus on implementing policy without the need to understand the complexity of creating the policy.

Figure 1 illustrates the components of this solution.

Figure 1- Ansible interface to Cisco Tetration Network Policy Publisher

Links to additional resources of this project are available on Code Exchange.

Simplify the Complex

Within IT operations, forming NetDevOps teams to integrate disparate systems is the model for high-performance organizations. While encouraging each team member to have general level of understanding of the organization’s goals, it is also important to include specialists in a technology, to leverage their deep experience in one area to increase the velocity of the team.

The project goal is to expose policy generated by Tetration in a simple format a network operator can use to enable defense in depth within their datacenter.

Figure 2 illustrates how the Python module tetration_network_policy, can be included in an Ansible playbook, retrieve a security policy and register the results as a variable.

Figure 2- Tetration Network Policy task

In this example, the variable tnp contains the Tetration Network Policy (inventory_filters, intents, tenant name and catch_all policy) for the requested Kafka topic. Subsequent tasks can reference these values and apply the security policy to network devices.

Figure 3 illustrates the contents of variable tnp, which will be used to generate access control lists on an ASA firewall.

Figure 3- Sample JSON formatted network policy

By exposing the policy to an Ansible playbook, the data can be easily reformatted to a traditional CLI configuration and applied to a firewall, load balancer or Cisco ACI fabric.

Use Case: Apply Policy to ASA Firewalls

Now that the network policy has been retrieved and loaded to a variable within the playbook, it can used to configure a network device. In this example, the target device is a Cisco ASA firewall.

By invoking the Ansible module asa_config, the network policy is used to create the appropriate CLI commands and apply them to one or more firewalls defined in the inventory.

Figure 4 illustrates the playbook syntax.

Figure 4 – Ansible module asa_config

Following the execution of the playbook, the sample JSON formatted network policy is present in the firewall configuration, as shown in Figure 5.

Figure 5 – ASA configuration

Note: Because SNMP is a well know port, the ASA CLI has substituted SNMP to reference port 161.

Continue reading

Serverless in the Datacenter: FaaS on K8s at DevNet Create

If you’ve ever wanted to learn the fundamentals of serverless and get your hands dirty building a LAMP-like application, DevNet Create has a session for you. On both April 24 and April 25 from 11:45a to 12:30p, I’ll be running an exercise entitled “FONK: FaaS on K8s working examples.” During our 45 minutes together, we’ll build a serverless version of the Guestbook application, which is the “Hello World” of the Kubernetes (K8s) community. Only instead of using containers directly the way that the original Guestbook does, we’ll use a Function-as-a-Service (FaaS) runtime, an Object Storage service, and a NoSQL server all running on top of K8s.

What is FaaS on K8s?

Developers need some platform providing them with compute resources in digestible bites when designing applications. Simply put, a Function-as-a-Service (FaaS) runtime (such as AWS Lambda or Azure Functions) is to serverless application architecture as a container runtime is to a microservices architecture. A container runtime takes care of things like autoscaling, rolling updates, and name resolution of different services running within it. A FaaS runtime obscures details of the underlying container runtime that most use under the hood and provide developers with a cleaner experience that enables them to focus on their own business logic.

During the session, we’ll discuss the six most popular FaaS runtimes that run on top of K8s so that you can run serverless applications in your own datacenter instead of in the public cloud. The featured labs will let you get your hands on two of them: OpenFaaS and OpenWhisk.

The Environment We’ll Be Using

I’ll be spending my evening on April 23 using a DevNet Sandbox to set up the following environment for you:

Each student will get a K8s cluster pre-configured with not only OpenWhisk and OpenFaaS runtimes but also an Object Storage service via Minio and a NoSQL server via MongoDB. An additional VM will be provided and preloaded with all the command line tools we’ll need to build an application as well. What does a web application look like when using this FONK design pattern?

Our End Goal: The FONK Guestbook

Instead of the traditional K8s Guestbook that uses three services and six persistent containers:

we’ll instead use the FONK design pattern to build its serverless equivalent:

Minio will host our static HTML and Javascript files. Upon being loaded into a browser, the Javascript will make REST API calls to the API gateway provided by our FaaS runtime to launch functions on demand. When loaded into memory as needed, those functions will perform read and write operations from and to our MongoDB. The Javascript will then alter our HTML in the browser to reflect the changes to our user.

Continue reading

Cryptographic Visibility: Quality Encryption at Your Fingertips

There is only one thing more important than the right answer, and that is asking the right question. I have spent my entire career doing security analytics and all of the useful analytics I have ever delivered to the market have been grounded in asking the right questions. With that in mind, I’d like to start this blog by asking you this:

How much of your digital business is transmitted in the clear versus encrypted and how would you assess the quality of that encryption?

I’ve spoken on Encrypted Traffic Analytics where most of the storyline is about detecting malicious traffic without having to perform decryption. However, that same telemetry used for malware detection can also be leveraged to answer those questions I posed to you above. With the release of Stealthwatch 7.0 and the new Cryptographic Audit App, I’m excited to take this opportunity to talk about features that can provide you near real-time visibility on the state of your network encryption.

Twenty years ago, you needed to be a network expert to bring up a cryptographic tunnel between endpoints or between networks. Today, most people don’t even know they are safely transmitting over strong cryptographic tunnels. Every time you type in https:// or the browser defaults to this, you make use of the Transport Layer Security (TLS) protocol, which makes your conversation safe and secure over even the most hostile networks. The ability to do something that once required deep knowledge and a thorough understanding of network architectures is now something most of us do on a daily basis without giving it so much as a second thought. It is truly amazing to me how far we have come since the birth of the Internet.

When network telemetry was first invented, the analytical outcomes were focused on questions like “Can host-A reach server-B?” Availability and network performance were the key objectives of the time, so telemetry like Netflow and IPFIX were the appropriate metadata needed to achieve these goals. Fast forward to today, where the digital business would also like to know “Is the connection between host-A and server-B secure?” In order to achieve this, Cisco had to innovate and developed an extension to NetFlow known as Encrypted Traffic Analytics telemetry, which Stealthwatch can analyze for you to give you the cryptographic visibility you need to govern your network security policies.

While it might not be obvious at first glance, the Cisco routers and switches are delivering telemetry, shown in the Sample Cryptographic Audit above, reporting critical metadata like the version of Transport Layer Security (TLS) being used, the Cipher Suites, and Key Lengths, all of which show what is happening across your digital business. For those of you who fall under PCI Compliance, you now have a way to provide evidence that for your PCI assets, you are running TLS version 1.1 or higher, as running TLS 1.0 would be a violation as of June 2018. Better still, after you clean things up, you can also setup alerts anytime something within PCI scope violates this policy – how awesome is that!

Let’s face it, TLS is the new TCP (Transmission Control Protocol). Having been at this for more than 25 years, I celebrate the fact that more than 90% of all network traffic these days is safely secured by cryptography. New versions of TLS get better, faster, and stronger which is awesome. While we throw a party for this achievement, lets also make sure we have systems in place to help us be vigilant and verify that what we intend to have happen is actually happening.

So, when it comes to the question of “How much of your digital business is transmitted in the clear versus encrypted and how would you assess the quality of that encryption,” Stealthwatch can provide you with an answer. With Stealthwatch 7.0, when your network tells you all this useful metadata, you can have a minute-by-minute status on your network visibility along with telemetry reports on critical metadata which now includes cryptographic details!

Continue reading

Automate Device Provisioning with Cisco IOS XE Zero Touch Provisioning

When new hardware is ordered and it arrives on site, it’s an exciting time. New hardware! New software! … But new challenges too!  But the age-old challenge of getting new devices on the network doesn’t need to be one of them. Sitting in the lab pre-provisioning devices is no longer required if you’re using Cisco IOS XE, because of features like Cisco Network Plug-n-Play (PnP) and Zero Touch Provisioning (ZTP). PnP is the premium solution made possible with Cisco DNA Center, while Zero Touch Provisioning (ZTP) is for the do-it-yourself customers who don’t mind investing more time in configuring and maintaining the infrastructure required to bootstrap devices. IOS XE runs on the enterprise hardware and software platforms that includes Catalyst 9000 series of switches and wireless LAN controllers, and the ISR 1000 and 4000 series routers.

DHCP Configuration to enable Zero Touch Provisioning

ZTP works when the DHCP client on the IOS XE device gets a DHCP Offer that includes option 67. This options, also called the “bootfile name,” tells the device which file to load and from where it’s available. Lets look at a few examples of how we can configure this on either the ISC DHCP Server or on the Cisco IOS DHCP Server.

The configuration example for the Linux ISC DHCP dhcpd.conf is below:

subnet 192.168.69.0 netmask 255.255.255.0 {
option bootfile-name "http://192.168.69.1/ztp.py"; }

For the Cisco IOS DHCP Server:

ip dhcp pool ZTP_DEMO
 network 192.168.69.0 255.255.255.0
 option 67 ascii http://192.168.69.1/ztp.py

In these examples option 67 points to a HTTP URL and a Python script. When the device see’s the python file in the option 67 then it downloads and executes it during bootup when no other configuration is present and without any manual user intervention. Pretty neat!

Next let’s take a look at a packet capture, which shows interesting things.

You might notice that the Client Identifier (option 61) is not consistent between DHCP Discovers. This is not a mistake, or multiple devices, but actually the intended behavior. Since IOS XE 16.8 the Client Identifier alternates between the device serial number, and the MAC address of the management port. When the DHCP server issues the DHCP Offer in packet 8, the bootfile-name (option 67) is set to http://192.168.69.1/ztp.py – This is the Python script that will be downloaded and run once the device is ready.

Once the device is ready?

Yes, a few things need to happen before the Python script can run. Specifically, the Guest Shell container must start up. This is a linux container that runs within the IOS XE platform. This container has limited access to the IOS XE subsystem. This means that if you decide to run a crypto-miner within Guest Shell (not recommended!) that the IOS XE device will still handle the routing and switching of packets without any problems as the resource allocations for Guest Shell are separate from those responsible for the core capabilities of the device.

The power of the CLI, now with the flexibility of Python

Guest Shell does have some nice feature, specifically the Python API. This API allows the Guest Shell to send commands to the IOS XE operating system. What kind of commands? Show commands are supported with the Python CLI module cli.cli. Show commands are great for displaying information about the device, but are limited when it comes to making device configuration changes. To really harness the power of the Python API, the cli.execute and cli.configure modules provide a great deal of flexibility when it comes to device configuration. We can interact with the device through Python using the traditional “configure terminal” (“conf t”) interface and even send exec commands as needed. All the power of the CLI, now with the flexibility of Python.

So our container has started, and it knows which file to access. Lets look at an example ztp.py script next.

This simple Python script sets the Vlan1 interface IP, enables some AAA settings, turns on the NETCONF-YANG programmatic interface, and creates a user. After, it prints the output to the screen, so that if we have a console cable connected we get visual confirmation that the device has been set successfully.

This device has now been automatically configured using ZTP. It received an IP address on the management port from DHCP, the Python configuration file from a webserver via DHCP option 67, it started up Guest Shell container and configured remote access. We are now free to carry on with our day-to-day tasks as the device is online and in a known and managed state.

Continue reading

ACI Anywhere Now Extending From On-Premises to AWS Cloud

Cisco is pleased to announce availability of a brand-new solution, Cisco Cloud ACI on AWS. This solution automates management of end-to-end connectivity and enforcement of consistent network security policies for applications running in on-prem data centers and AWS public cloud regions.

Decentralized Data Means Cloud Growth

Enterprises, large and small, are expanding to the cloud to build applications that engage their customers. And their developers and IT teams must manage their private and public cloud environments.

IDC expects spending on cloud IT infrastructure to grow at a five-year compound annual growth rate (CAGR) of 11.2%, reaching $82.9 billion in 2022, and accounting for 56.0% of total IT infrastructure spend. Public cloud data centers will account for 66.0% of this amount, growing at an 11.3% CAGR. Spending on private cloud infrastructure will grow at a CAGR of 12.0%*.

Due to this massive shift in the decentralization of data, increasing cloud acceptance, and move to hybrid environments, businesses need a network that can empower the data center to go securely anywhere. Innovation should only be limited by imagination, not technology. Cisco’s ACI Anywhere with Cloud ACI is the bridge.

Multicloud Doesn’t Need to Mean Complexity

As the adoption of multicloud strategies grow, the industry is demanding consistent policy, security, and visibility everywhere, with a simplified operating model. IT organizations are challenged to maintain governance, compliance, agility, flexibility, and TCO optimization for legacy, virtualized, and next-generation applications across multiple on-premises sites and clouds.

Highly complex operational models today are the result of diverse and disjointed visibility and troubleshooting capabilities, with no correlation across different cloud service providers. There are multiple panes of glass to configure, manage, monitor, and operate these multicloud instances. And there are inconsistent segmentation capabilities today across hybrid instances that pose security, compliance and governance challenges.

Cisco Cloud ACI Extends ACI Capabilities from On-premises to Public Cloud

Cisco ACI delivers control and visibility based on application network policy. With the next phase, Cisco ACI extends this policy-driven automation from on-premises to public cloud instances.

Cisco Cloud ACI runs natively in public clouds and delivers the following key capabilities:

Automated and secure hybrid connectivity through unified management. Through a single pane of glass (ACI Multi-Site Orchestrator), users can configure inter-site connectivity, define policies, and monitor the health of network infrastructure across hybrid environments. Inter-site connectivity includes (i) An underlay network for IP reachability (IPsec VPN over the Internet, or through AWS Direct Connect*) and (ii) an overlay network between the on-premises and cloud sites that runs BGP EVPN as its control plane and uses VXLAN encapsulation and tunneling as its data plane.

Enable consistent security posture, governance, and compliance through a common policy abstraction. Cisco ACI on AWS uses group-based network and security policy models.Cloud ACI translates ACI policies into cloud-native policy constructs. The logical network constructs of Cisco ACI (tenants, VRFs, endpoint groups (EPGs), and contracts etc) translate into AWS networking constructs (user accounts, Virtual Private Cloud (VPC), and security groups, plus security group rules and network access-control lists etc.). This enables consistent network segmentation, access control, and isolation across hybrid deployments.

Enable elasticity for resources across on-premises data center and public cloud. Enable secure workload mobility and preserve the application policies, network segmentation, and identity of the workload (IP mobility*).

Facilitate workload migration across hybrid environments. Enable secure workload mobility and preserve the application policies, network segmentation, and identity of the workload (IP mobility*).

Enable business continuity and disaster recovery. Allow organizations to maintain or quickly resume mission-critical applications using a back-up and recovery site in the public cloud.

What makes Cisco’s Cloud ACI different and relevant for you

Cloud ACI provides a common policy abstraction and consumes AWS public APIs to deliver policy consistency and segmentation. As such, Cloud ACI is not confined to bare-metal instances in AWS and does not require deployment of agents in cloud workloads to achieve segmentation.

With Cisco ACI, customers can carry all their network and security policies across data centers, colocations, and clouds. Cisco ACI automates cross-domain service chaining of application traffic across physical and virtual L4-L7 devices to scale, and seamlessly integrates bare-metal servers, virtual machines, and containers under a single policy framework.

Cisco ACI also has the industry’s broadest tech-partner ecoysystem and integrates with a variety of solutions ranging from Cisco AppDynamics, CloudCenter to F5, ServiceNow, Splunk, SevOne, and Datadog. Customers can leverage widely adopted tools such as Terraform and Ansible to achieve end-to-end workflow-based automation. AWS customers can tap into the rich cross-silo insights through ACI integrations with AWS technologies like Amazon CloudWatch* and Amazon Simple Notification Service (Amazon SNS)* to fine tune the network for better throughput, latency, path selection, security and cost optimization.

Have ACI Anywhere with Cloud ACI on AWS

As the industry’s most deployed, open SDN platform, Cisco delivers advanced capabilities on AWS and simplifies multicloud deployments with Cisco Cloud ACI. With the Cloud ACI architecture, customers and analysts see the benefit of seamless layer-in policy consistency, operational simplicity and the flexibility to leverage services offered by public clouds.

“ESG Research validates that companies are increasingly adopting a hybrid cloud approach to deliver the best service for their customers. In fact, many are adopting a Multicloud policy” says Bob Laliberte, Practice Director and Senior Analyst with the Enterprise Strategy Group. “However, these distributed compute environments create significant management complexity. Cisco ACI Anywhere, and more specifically, Cloud ACI on AWS is helping to consolidate and simplify management across the on-premises data center and the popular AWS cloud environment, something that we expect will be well received by all market segments.”

Continue reading

Simplifying Container Orchestration with Cisco Hybrid Solution for Kubernetes on AWS

For organizations that are adopting DevOps practices and modern cloud capabilities to accelerate innovation and gain competitive advantage, one of the biggest challenges is maintaining common and consistent environments through an application’s lifecycle from development through to deployment. Containers solved the application portability problem of packaging all the necessary dependencies into discrete images, and Kubernetes has emerged as the defacto standard for how those containers are orchestrated and deployed.

By adopting containers and Kubernetes, IT and Line of Business users can focus their efforts on developing applications, rather than infrastructure and ‘plumbing’. Because Kubernetes is available everywhere, one can choose the best place to run an application based on business needs. For some applications, the scale and reach of the public cloud, along with its huge number of services available, will be the determining factor. For others, data locality, security or other concerns dictate an on-premises deployment.

Current solutions can be complex, requiring organizations to work across either isolated or separate environments and forcing teams to “glue” all the parts together themselves, at the expense of time and money. This can result in less choice by forcing organizations to choose between on-premises and public clouds or being limited by “all-or-nothing” stacks.

To help our customers with this challenge, Cisco announced today our collaboration with AWS to create the Cisco Hybrid Solution for Kubernetes on AWS. The new solution combines Cisco, AWS and Open Source technologies to simplify complexity and eliminate challenges for customers turning to Kubernetes to enable deploying applications across on-premises and the AWS cloud in a secure, consistent manner. It provides a tested, validated and simple solution that delivers consistent Kubernetes clusters both on premises and in the cloud, leveraging the best attributes of each. This reduces the burden on different teams with respect to people, processes and skill sets, accelerating the application deployment cycle and resulting in faster innovation. Customers can extend on-premises capabilities and resources to AWS cloud as well as utilize services and resources from AWS cloud on-premises.

Solution Overview

The core component of the The Cisco Hybrid Solution for Kubernetes on AWS is a unique integration between Cisco Container Platform (CCP) and Amazon Elastic Container Service for Kubernetes (EKS) so that through the single CCP management UI, the customer can provision clusters both on-premises and on EKS in the cloud. CCP uses AWS IAM authentication to create the VPC, instructs EKS to create a new cluster, and then configures the worker nodes in that cluster.

With Cisco Hybrid Solution for Kubernetes on AWS, customers use the CCP UI to launch Kubernetes clusters in Amazon AWS in addition to on-premises environments. They simply declare their Kubernetes cluster specification and reference the cisco managed operating system images for the worker node images to deploy clusters in either environment. AWS Identity and Access Management (IAM) is integrated as common authentication mechanism, so that the cluster administrator is free to apply the same role-based access control (RBAC) policies across both environments. Both environments are integrated with Amazon Elastic Container Registry (ECR), providing a secure, single repository for all the container images. A standard set of Open Source monitoring and logging tools based on Prometheus and ElasticSearch/FluentD/Kibana (EFK) stack is deployed to the clusters to provide consistent logging and metrics. Finally, Cisco’s site-to-site VPN solutions, such as CSR 1000v are leveraged to provide a range of secure connectivity options between the cloud-hosted and on-premises services.

Cisco offers a single point of contact for support across all the components of the solution (including AWS components – EKS, IAM and ECR) – as opposed to having to seek support for each component separately from different vendors.

Using Cisco Container Platform to Provision Kubernetes Clusters in Amazon EKS and on-premises

To see what this looks like in practice, lets walk through how the administrator would create an EKS cluster using the Cisco Container Platform (CCP) dashboard.

Provisioning an EKS clusters is as simple as a few button clicks. You first define AWS as your infrastructure provider. This includes a provider name, and AWS account credentials.

Note: The AWS account credentials specified here will be the AWS IAM identity that has privileges to manage the EKS cluster.

Next, you specify basic information about your Amazon EKS cluster. This includes the AWS region you want to deploy the EKS cluster in, an optional IAM user or role that you want allowed additionally to manage the EKS cluster, a cluster name and the Kubernetes version for the cluster.

Finally, you configure information about the EKS worker nodes. This includes the instance types, machine image, number of worker nodes and public ssh keys.

And that’s it! Behind the scenes, CCP uses the Amazon APIs to provision the following resources:

◈ A new VPC (including subnets, security groups, route tables, etc.) in your account in accordance with AWS best practices, with secure private and public subnets as recommended by Cisco for VPN interconnection

◈ A service role for EKS

◈ A node instance profile for the EKS worker nodes

◈ An EKS cluster

◈ An autoscaling group with EKS worker nodes

◈ A configMap on your cluster that allows the worker nodes to join the master

Once the cluster is deployed, you can download a pre-generated Kubernetes cluster config file ( ~/.kube/config) . CCP leverages the open source aws-iam-authenticator kubectl plugin that uses credentials from your local ~/.aws/credentials file to authenticate an AWS IAM user with the EKS cluster.

For on-premises Kubernetes clusters deployed and managed by CCP, the solution offers an integrated experience with Amazon Cloud. As part of the integration with AWS, you can now select the “enable AWS IAM” option, which will install the AWS IAM authenticator components in the newly created on-premises Kubernetes cluster. This allows you to use a single set of AWS IAM credentials to access Kubernetes clusters both on-premises as well as in EKS.

With clusters provisioned in cloud and on-premises environments, let’s take a deeper look at each of the AWS integrations in Cisco Hybrid Solution for Kubernetes on AWS.

Common IAM Identity for Authentication with a common RBAC policy for Authorization

CCP leverages the open source AWS IAM authenticator to enable a common AWS IAM user/role to authenticate with clusters in both cloud and on-premises environments. Once the user/role authenticates with the clusters, a configurable common RBAC policy defines the specific permissions that the user/role is authorized to perform within the respective clusters. As a result, you have to simply switch context using a common “kubectl” cli tool to access either environment.

By default, the AWS credentials specified at the time of Amazon EKS cluster creation are mapped to the Kubernetes ‘cluster-admin’ ClusterRole (the “system:managers” group ClusterRoleBinding). This IAM identity has administrative control of the EKS cluster. As noted before, you can optionally specify an additional AWS IAM role or IAM user as Amazon Resource Name (ARN). When you specify this, CCP:

1 )  Maps an additional associated role in the EKS cluster configMap as illustrated below:

2)  Adds the associated role to the kube config so that the AWS IAM authenticator can use that role to authenticate with the EKS cluster as shown below:

For the on-premises cluster, you can enable the AWS IAM integration to authenticate with the cluster using the same IAM identity. You do this by specifying the ARN of an AWS IAM user during the on-premises cluster creation process. CCP similarly maps this user to the Kubernetes ‘cluster-admin’ ClusterRole in the on-premises cluster’s configMap. It also updates the on-premises cluster’s kubeconfig which in-turn enables the AWS IAM authenticator client to authenticate with the on-premises cluster using the same IAM identity.

With IAM configured as described above, it is then possible to use a common RBAC policy applied to Kubernetes clusters either an EKS or on-premises to control access to resources.

Common Amazon Elastic Container Registry (ECR)

CCP integrates with ECR, providing a secure, single repository for all the container images.

For Amazon EKS worker nodes, CCP automatically provisions an instance-role that has permissions to read/write from an ECR repository.

Since on-premises nodes have no such role, an additional step is necessary – the credentials must be stored in a Kubernetes secret which is then referenced by the pod manifest (see below). A script such as the following will do that for you (replace the items in [] as appropriate).

This script fetches an authorization token from AWS and stores it in a Kubernetes secret which is read during the pod deployment. Note that it is necessary to periodically refresh this token. By default, the token expires after 12 hours.

After running the script above, you can deploy a kubernetes manifest via kubectl, specifying the relevant details of the ECR repository, as you normally would. The example pod manifest below demonstrates how the ECR repository used by an application is specified in the image property.

To pull images from an ECR registry, it is necessary to provide credentials. This is described in Amazon’s ECR documentation. For a user running docker, i.t looks like this: (ecr:GetAuthorizationToken privileges are required), while Kubernetes will use the credentials stored in a Kubernetes secret as described earlier and specified in the “imagePullSecret” in the pod manifest.

With CCP, you can deploy both your on-premises and Amazon EKS worker nodes with the same Kubernetes version and operating system.

At launch, you can deploy Kubernetes v1.10 with Ubuntu 18.04 worker nodes, using Cisco-provided images. You do not have to worry about Kubernetes and operating system version inconsistencies across siloed environments. Updates and security patches across the on-premises and AWS environment are handled seamlessly and provided via the CCP control plane software.

Common Monitoring and Logging

CCP provides integrated cluster monitoring via a Prometheus and EFK stack (ElasticSearch/FluentD/Kibana) that is deployed within each cluster deployed by CCP. Monitoring each cluster is in compliance with best practices that mandate separation of production data from development data and for keeping information local for GDPR. It also ensures that logs and metrics are not reliant upon a central service which could be unavailable. Cisco Services can help with log forwarding and central metrics collection as well as integration with customer’s own logging and metrics systems as desired.

Value-added Integrations for Connectivity, Security and Monitoring

Cisco’s extended cross-portfolio solutions provide a range of value-added solutions that can be leveraged from the AWS marketplace to complement the Cisco Hybrid Solution for Kubernetes on AWS.

These include:

◈ Application Deployment: Use Cisco CloudCenter to securely deploy both Kubernetes and VM-based workloads across both private and public infrastructure.

◈ Connectivity: Use Cisco CSR1000v to establish VPN connectivity between hybrid on-premises and cloud environments

◈ Security: Deploy Cisco Stealthwatch to monitor network traffic application traffic for anomalies, leveraging AWS flow logs for cloud-based workloads.

◈ Monitoring: Enable AppDynamics application performance monitoring to see the real-time impact that application performance has on your business results.

Continue reading

A guide to maximizing your chances of success with IoT

“Dream big, start small.” This may sound like a clichéd phrase from a motivational poster, but it’s actually a very valuable piece of advice for enterprises to heed when deploying Internet of Things (IoT) initiatives.

By now, we all know that IoT has the power to drive digital transformations across industries by creating new value propositions, business models, services and markets. However, as I speak with frontline business and operations managers from enterprises around the world, I’ve found that many are still unsure how and where to begin their IoT journeys. They have big ideas and aspirations, but often struggle to see their project through. In fact, 60 percent of IoT initiatives don’t move past the proof of concept stage, and just 26 percent of organizations consider their IoT initiative a success.

Whether you’re embarking on your first or fiftieth IoT project, you need to do some careful planning to yield tangible results. Often that means starting with the low-hanging fruit – realizing some quick successes with a fast ROI and then scaling your projects into additional areas of the business for more ambitious results.

Condensed from my interactive book, “Building the Internet of Things – a Project Workbook” here are the 10 steps I recommend organizations take to maximize the chances of success with their IoT projects. Some of these might seem basic and common sense. However, based on my experience with dozens of IoT implementations across industries, I have discovered that these guidelines are often overlooked.

Identify your IoT project vision: First start small, but never lose sight of your end goals. IoT is a technology tool, and your IoT project is a means to an end. Therefore, you must first clearly define your business-oriented “why.” Why do you want to implement IoT, and what business goals do you plan to achieve? Here, consult cross-functional teams for input and to help secure buy-in from your higher-ups. If you skip this step, you will end up fragmenting your efforts on one-off projects, rather than creating a foundation for true digital transformation across your organization.

Define your use case: What is the specific business problem you want to solve? I recommend starting with one of four “fast paths” to IoT payback that focus on improving existing processes and thus reducing costs: connected operations (linking devices, sensors and meters to a network); remote operations (monitoring, control and asset management); predictive analytics (identifying and understanding where to take action); and preventative maintenance (increasing uptime and productive hours). Further down the road, you can start leveraging IoT to generate new revenue streams, business models and value propositions, as well as map out new go-to-market strategies, market disruptions and more.

Determine your skill requirements. People, not just the technology itself, determine the success of your IoT journey. Therefore, evaluate the readiness of your team and its skillsets to support your IoT initiative. Large IoT projects require people with soft-skills – not just technical knowledge– to build trusted relationships and virtual teams across departments and functions, listen and communicate, as well as secure buy-ins and on-going support and sponsorship from peers, executives and partners.

Benchmark your organization against your industry peers: This step will help establish metrics you can use to validate your project and determine how far you’ve come upon its completion. I suggest benchmarking your organization in the following areas: IT and OT convergence (not only at a technology level, but also organizational, architectural and business process); innovation environments (your workforce’s capabilities and appetite for innovation); partner ecosystems; customer relationships; and level of IoT experience. Use the results to identify gaps you need to address prior to starting the project.

Assess your technological readiness: Consider whether you’ll be able to connect and access all data and, at least, major functions of IT and OT groups via open and interoperable technology stack. Do you need to integrate islands of data? Do you have plans to consolidate networks onto IP? Rest assured that you don’t necessarily need to overhaul your legacy system from the start, especially if you are starting small. You can begin by connecting existing systems within your organization, then gradually introduce other elements of flexible frameworks.

Assess your cultural readiness: From the C-Suite to your workforce and across your partner’s ecosystem, your organization must be ready and willing to support your project. Here, it’s important to assess how well key functions tend to work together, how well they communicate with each other as well as with key stakeholders (including customers), what changes to the culture your initiative will require and what changes it will bring.

Develop the value proposition for your business case: As you prepare your organization for IoT’s required cultural change, IT managers will want to know the expected ROI of your project. Do your best to estimate a hard number, considering patterns of payback where IoT delivers the greatest value (see step 4), while taking into account the cost of new technology, human capital, device connections and cultural change.

Identify and connect devices, technologies and system: This critical step involves creating your project’s blueprint. Define your technology framework and how it needs to integrate with your existing systems and with the business processes. Make sure that your framework is not applicable only to your first project, but that it can also scale across your organization down the road and is flexible enough to integrate future technologies.

Address security:Take a rational, risk-based, architectural approach to IoT security. Partner with your Chief Information Security Officer to create a unified and policy-based security architecture that is imbedded into every aspect of your technology stack and workflow. Develop a plan for how you’ll handle security incidents before, during and after an attack. Leverage industry best practices and tools (don’t reinvent the wheel) such as device and traffic segmentation to safeguard your infrastructure from end to end. In addition, implement processes and checks to ensure the accuracy and validity of your IoT data flows. Identify the data you plan to capture and apply the appropriate business rules or logic needed to process or analyze it for meaningful results.

Measure Success:As you put your plan into gear, measure your successes (and even failures) along the way. Refer back to your baseline metrics established during the benchmarking step; identify what worked, and where you need to improve. Once you realize results – big or small – look for ways to replicate and scale your initiatives across other areas of your business.

Continue reading