Summary

In this lab, you will learn how to configure and use Apigee API Management for Istio. Apigee API Management for Istio provides basic API gateway policies that can be applied to your microservices in a service mesh.


    # istio handler configuration for apigee adapter
    # generated by apigee-istio provision on 2018-06-18 15:29:31
    apiVersion: config.istio.io/v1alpha2
    kind: apigee
    metadata:
      name: apigee-handler
      namespace: istio-system
    spec:
      apigee_base: https://istioservices.apigee.net/edgemicro
      customer_base: https://myorg-myenv.apigee.net/istio-auth
      org_name: myorg
      env_name: myenv
      key: 06a40b65005d03ea24c0d53de69ab795590b0c332526e97fed549471bdea00b9
      secret: 93550179f344150c6474956994e0943b3e93a3c90c64035f378dc05c98389633

Apply the Apigee definitions for Istio. This defines the CRDs for Apigee.


kubectl apply -f samples/apigee/definitions.yaml

OUTPUT:


customresourcedefinition "apigees.config.istio.io" created
customresourcedefinition "analytics.config.istio.io" created
analytics "apigee" created
authorization "apigee" created

NOTE: if you notice a failure when running this command, please run it again. The error should be resolved.

Apply the Apigee handler to Istio. The handler tells Mixer how to connect (securely) to Apigee.

kubectl apply -f samples/apigee/handler.yaml

OUTPUT:

apigee "apigee-handler" created

and finally, apply the rule. This tells Istio when to apply Apigee rules.

kubectl apply -f samples/apigee/rule.yaml

OUTPUT:

rule "apigee-rule" created

NOTE: in the sample rule, we apply Apigee rules to any service in the default namespace. This will prevent your UI from showing book details. But that is expected. We expect JWT tokens to access the details service and the productspage is not sending it.

Recap

In the previous workshop we deploy the bookinfo application, exposed the details API and protected it via JWT. In this workshop, we're going to provide secure access to the API and generate usage/analytics metrics.

Publish the API as a Product

The first step will be to create an API Product in Apigee Edge.

Login to Apigee Edge Use your Apigee credentials to login in.

Select Publish from the Edge UI

Select API Products under publish

Create a new product

Enter Product details

Name: A Product Name
Environment: which environment the API Product is available in
Resouces: Which API Paths you want to expose
Attributes: Add a custom attribute called istio-services. The values are a comma separated list of Istio services (FQDN).

Consume an API Product

Generally speaking, you would now go to the Apigee portal and request keys for the API Product we just created. To keep the lab simple, we will create those artifacts a portal would have through the Edge UI (Admin interface)

Select Developer App from the Edge UI

Create a new Developer App

Enter Developer App details

Name: A new for the developer app
Developer: The name of the developer who is authoring the app (client application)
Product: A list of API Products

Make a note of the credentials

Obtain a JWT Token

We will now use the apigee-istio CLI interface to obtain a new JWT token. The CLI interface is for convenience only. In production, client applications will use APIs to get an new JWT token.

export TOKEN=`apigee-istio token create -o amer-demo13 -e test -i xxx -s xxx`

The output is stored in an environment variable.

Make an API Call

Now, we are ready to try the API again:

curl $GATEAWY_URL/details/0 -H "Authorization: Bearer $TOKEN"

OUTPUT:

{"id":0,"author":"William Shakespeare","year":1595,"type":"paperback","pages":200,"publisher":"PublisherA","language":"English","ISBN-10":"1234567890","ISBN-13":"123-1234567890"}

We have now successfully exposed an API to consumers outside the service mesh.

View API Analytics

The Apigee adapter for Istio is able to send API usage/metrics asyncronously to the Edge UI. In about 5-6 mins, you should be able to see usage metric for details showing up like this:

Expose the API to third parties

When exposing APIs externally, especially to third parties, the API Management policies you want enforced are typically different (more security focused) than when the API is used internally.

For APIs are exposed externally, you'd probably want:

Some form of rate limiting
JSON/XML threat protection (Minimizes the risk posed by content-level attacks by enabling you to specify limits on various XXML/SON structures, such as arrays and strings)
Quotas (different from the ones you'd give internal users)

Apigee's API gateway provides with exactly such policies. In this part of the lab, you will create a proxy in Apigee Edge and have external users proxy requests through the Apigee Gateway.

./importproxy.sh {username} {password} {orgname} {envname}

This should deploy a proxy called details in your org and deploy it to the environment that was specified in the CLI.

Access the API

Try accessing the API from the endpoint published in Apigee.

curl https://{org}-{env}.apigee.net/details/0 -H "Authorization: Bearer $TOKEN"

Restrict access to IPs

The details API is available on a public IP GATEWAY_URL. Nothing prevents an external user to bypass Apigee and access the endpoint directly. It is a good thing we still require OAuth tokens to access the endpoint, but we still want only Apigee's proxy to access the endpoint.

Istio provides a native adapter (listchecker) to whitelist or blacklist IPs. The following steps will show you how to use it.

Obtain the IP address of Apigee Edge

curl -X GET https://api.enterprise.apigee.com/v1/o/{org}/eips -u {user}:{pass}

OUTPUT:

{
  "podEips" : [ {
    "eips" : [ ],
    "pod" : {
      "name" : "pxx0rt000-0",
      "region" : "us-east-1"
    }
  }, {
    "eips" : [ "xxx.xx.xxx.xx", "xx.xxx.xxx.xx" ],
    "pod" : {
      "name" : "pxx0mp000-0",
      "region" : "us-east-1"
    }
  } ]
}

The eips field contains the IP addresses assigned to the Apigee gateways.

Configure Mixer to allow only those IPs This section contains three parts:

listchecker: provide a list of ips to whitelist
listentry: provide the location of the ip
rule: when do i apply this adapter, in this case, when the call comes to the ingress

apiVersion: "config.istio.io/v1alpha2"
kind: listchecker
metadata:
  name: ip-listchecker
  namespace: istio-system
spec:
  entryType: IP_ADDRESSES
  overrides: [ "107.23.127.92", "54.210.253.51" ]
  blacklist: false
---
apiVersion: config.istio.io/v1alpha2
kind: listentry
metadata:
  name: ip-value
  namespace: istio-system
spec:
  value: source.ip
---
apiVersion: "config.istio.io/v1alpha2"
kind: rule
metadata:
  name: ip-rule
  namespace: istio-system
spec:
  match: destination.labels["istio"] == "ingressgateway" && source.service == "details.default.svc.cluster.local"
  actions:
  - handler: ip-listchecker.listchecker
    instances:
    - ip-value.listentry

[WIP: this step is not complete yet]

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

README.md

README.md

Summary

Table of Contents

Setup and Requirements

Installing Apigee API Management for Istio

Upgrade Istio

Provision Apigee for Istio

Recap

Publish the API as a Product

Consume an API Product

Obtain a JWT Token

Make an API Call

View API Analytics

Expose the API to third parties

Access the API

Restrict access to IPs

Files

README.md

Latest commit

History

README.md

File metadata and controls

Summary

Table of Contents

Setup and Requirements

Installing Apigee API Management for Istio

Upgrade Istio

Provision Apigee for Istio

Recap

Publish the API as a Product

Consume an API Product

Obtain a JWT Token

Make an API Call

View API Analytics

Expose the API to third parties

Access the API

Restrict access to IPs