Sunday, April 4, 2021

CentOS on WSL2

The CentOS Linux distribution is a stable, predictable, manageable and reproducible platform derived from the sources of Red Hat Enterprise Linux (RHEL). The CenOS distribution is quite popular in my professional life.

Having switched to WLS2 - Windows Subsystem Layer - on my local machine, I was lacking CentOS. According to the docs, WLS2 can import whatever Linux distro one prefers. 

But I found WSLDL the more trivial option. With support for many distros. For CentOS, simply download CentOS-WSL and off one goes.



Monday, February 15, 2021

Take Apigee X for a spin

Apigee X is the latest product version of Google's Apigee API Management platform. Adding a 4 product version next to Apigee Edge (SAAS), Apigee for Private Cloud and Apigee Hybrid. Apigee X is best described as a version of Apigee Hybrid that is (almost) fully managed by Google.

There is a free evaluation version available. One only needs a (free) Google Cloud account. Took it for a spin on a snowy Sunday afternoon.

The suggested way to get started with Apigee X is the Apigee Evaluation Setup. But if you want to experiment with API proxies that are publicly available, better use the apigee-ngsaas-trial-install.sh script.

Create a Google Cloud project and assign the Apigee Organization Admin role to yourself.

Then simply start the script. One attention point when using the Cloud Shell terminal: the script takes a long time to execute, causing your shell to close. I solved this by restarting the script after the organization was provisioned. Then opening the Apigee console.

Configured an API proxy "httpbin" pointing to http://httpbin.org/ for my project (apigee-x-2021 with LB IP 34.117.205.203).. And invoke the API proxy:

curl -k -v https://apigee-x-2021-eval.apigee.net/httpbin/uuid \
        --resolve "apigee-x-2021-eval.apigee.net:443:34.117.205.203"
 
There are limited costs related to the use of this Apigee X eval. A number of objects are created by the script on GCP to expose the API proxies publicly. Estimated cost for these components is €0,07/hour. The Apigee X trial itself is of course free.
 
  • 2 VM instance (apigee-envoy-xxxxx)
  • Instance group (apigee-envoy-europe-west1)
  • Instance template (apigee-envoy-europe-west1)
  • Forwarding rule (apigee-envoy-https-lb-rule)
  • Load balancer (apigee-envoy-proxy-map)
  • With backend (apigee-envoy-backend)
  • Target proxy (apigee-envoy-https-proxy)
  • SSL cert (apigee-ssl-cert)
  • Static IP address (lb-ipv4-vip-1)



Saturday, February 13, 2021

From WS-Security to API Message Security?

API Management - and application integration in general - go hand in hand with good security practices. It is crucial to protect the message exchanges between all the systems we link together. This article focuses on the integrity of API requests and responses. Where we still lack a broadly accepted approach or standard.

From XML Signature to WS-Security

The XML spec (1998) was created with a lot of related specifications such as XPath (1999). On the security side, XML Signature (2002) and XML Encryption were rapidly available. These standards were the foundation for WS-Security, with it's most relevant use case, the X509 Token Profile (2004).

XML Signatures have some great features:

  • Embedded within the XML document itself (detached also supported)
  • Normalization of the message before calculating the hash, the "canonicalization" or C14N
  • Specific parts of the XML message can be signed
  • Multiple signatures of parts of single XML document
BTW, best book ever on WS-Security and related remains "Securing Web Services with WS-Security: Demystifying WS-Security, WS-Policy, SAML, XML Signature, and XML Encryption".

JSON Message Level Security

On the JSON side, we have the JSON Web Signature (JWS) spec (RFC7515, 2015). JWS is the basis for JSON Web Tokens (RFC7519). Although a JSON canonicalization standard exists - albeit not very popular - with JSON Canonicalization Scheme (RFC8785), the JWT spec opted to base64 encode the message, turning JSON into non-JSON.

JWT or jot tokens are well supported and very useful for JWT tokens, e.g. the identity tokens of OpenID Connect.

API Message Level Security?

In the API world, SSL/TLS is the foundation for secure exchange of information. There is no tendency whatsoever to apply protection on the request or response level. A bit weird, where 15+ years ago we went through great lengths to protect XML messages while going over multiple network hops. In the API world, we seem to believe that there is only a single network hop between client app and back-end API? No API Management or other components along the road? 

There is no standard (approach) yet to provide message level protection of our API requests and responses. Where "message body" is the resource representation of and API responses or the request body with HTTP POST, PUT or PATCH verbs.

The draft HTTP signatures RFC is an important step for message level API security. Where HTTP headers are being signed. And where the body can be included in that signature by adding the hash of the body as a Digest header cf. RFC3230

The Signing HTTP RFC has difficulty getting "finished". The "old" Signing HTTP Messages draft RFC is now being succeeded by the new draft Signing HTTP Messages RFC. A lot of topics for discussion remain. With an important one missing: reference to JWKS or X509 client certs (x5c) for signature verification.

Where is the "API Security" spec?

But where is the overarching approach? Where HTTP signing includes the message body, with canonicalization based on the content-type: JSON C14N, XML C14N or other? Where is the successor of WS-Security in the API world?

And as a nice extra: where is the successor of Web Services Security X.509 Certificate Token Profile so we can continue using X509 client certs as alternative for JWKS?

Saturday, January 30, 2021

Cloud Ready Containers with WSL2

RedHat OpenShift is a popular, enhanced and extended version of Kubernetes. Available on numerous platforms, also locally as Cloud Ready Containers (CRC).

Have been fighting a bit to get the combination of CRC with WSL2 working on my Windows machine. Wasn't able to reach the OpenShift cluster form my WSL2 Linux machines.

Big thanks to colleague Stefaan De Geyter of sister company FlowFactor for hinting me the Set-NetIPInterface command. The Set-NetIPInterface -Forwarding Enabled command allows WSL2 to interact with the CRC VM.

Execute the below commands from PowerShell as Administrator:

Get-NetIPInterface | where {$_.InterfaceAlias -eq 'vEthernet (Default Switch)'} | Set-NetIPInterface -Forwarding Enabled

Get-NetIPInterface | where {$_.InterfaceAlias -eq 'vEthernet (WSL)'} | Set-NetIPInterface -Forwarding Enabled

To double check that forwarding is enabled:

Get-NetIPInterface | select ifIndex,InterfaceAlias,AddressFamily,ConnectionState,Forwarding | Sort-Object -Property IfIndex | Format-Table

One drawback: after wake-up or reboot, need to enable forwarding again, a known issue.

As such one can install the OpenShift command line tools on WSL2 Linux instances and happily "oc" against the the local CRC cluster.


Tuesday, January 15, 2019

Service Mesh - Event Mesh??

Service Meshes and Istio in particular are the next step in modern software platforms. They further standardize the runtime platform and help abstract the underlying layers.

Now service meshes strongly focus on synchronous request/reply (request driven) interactions. Their data plane is based on advanced usage of proxies, Envoy in case of Istio. Primarily protocols are HTTP 1.1 and 2.0, with some gRPC.

But a micro services architecture also requires event driven communication. Some question/idea that came up: why not use a messaging solution (pub/sub and/or queuing) as the data plane of a service mesh?

Multiple types of messaging systems exist: compliant with the JMS API, compliant with the AMQP protocol or modern incarnations such as Kafka or NATS.

Event Mesh (source: Solace.com)
While searching around, couldn't find much support for such "event mesh". Solace is a lesser known vendor of messaging solutions that talks about its event mesh in its blog and positions it as an offering. But couldn't find information on how to use Solace's product as a data plane for in a service mesh such as Istio or Linkerd.

Strange that no other vendors or initiatives talk about using a Message Oriented Middleware (MOM) as the data plan of a service mesh. It is common practice in the integration world to switch from http to messaging inbound. And leverage light weight integration platform as ingress for a service mesh?

Friday, September 21, 2018

Kubernetes in Action

Kubernetes is becoming a very popular platform to manage containers. There is a consensus in the i8c team that the book Kubernetes in Action is really a great way to dive into the matter. By reading the book, one also grasps the complexities of Kubernetes.

Interesting to see how all the big names
Google, Amazon, Microsoft, IBM, Pivotal, Redhat  support the Kubernetes platform in their respective clouds and on-premise. The list of Kubernetes Certified Service Providers is extensive.

Also integration platforms are being containerized, e.g. TIBCO BusinessWorks Container Edition or IBM AppConenct Enterprise. But other vendors in the integration space are taking this direction as well: multiple lighter-weight integration engines running a limited number of integration flows. Whereby containers can run distributed on-premise and in different clouds.

Tuesday, September 18, 2018

Marrying API management with Istio

Istio is a service mesh on top of Kubernetes. Istio assists with the securing, managing and monitoring the communication between microservices.

The two main drivers behind Istio, IBM and Google (Apigee) both have a strong API Management solution. IBM comes with API Connect, Google with Apigee. Now both IBM and Google are definitely going to bring their API Managemet solution together with Istio. 

Apigee has already released a "Apigee Adapter for Istio" that we successfully took it for a spin.

IBM is releasing papers describing API + Microservices Management as the perfect marriage.

A topic to closely monitor as it brings enterprise API Management and Micro Services together!