layer7-operator

README

Layer7 Gateway Operator

The Layer7 Gateway Operator, built using the Operator SDK covers all aspects of deploying, maintaining and upgrading API Gateways in Kubernetes.

Note: The Operator examples currently use Gateway 11.0.00_CR2 as a base. The OTel examples use a custom 11.0.00_CR1 image.

About

The Operator is currently in an Alpha state and therefore does not currently carry a support/maintenance statement. Please check out the Gateway Helm Chart for supported container Gateway Deployment options

The initial release gives basic coverage to instantiating one or more Operator managed Gateway Deployments with or without an external MySQL Database.

The Layer7 Operator is restricted to manage the namespace it's deployed in by default. There is also a cluster-wide option available where the operator can watch all or multiple namespaces.

Documentation

• API (Custom Resource) Docs
• Wiki
• Techdocs (coming soon)

Compatibility Matrix

The Layer7 Operator graphman client is strongly typed, meaning changes to the Graphman Schema can cause breaking changes between versions of the Operator/Gateways.

Operator Version	Gateway Versions
v1.0.4	10.1.00_CR3, 11.0.00_CR1
v1.0.5	10.1.00_CR4, 11.0.00_CR2

Deployment Types

Application Level

• Database Backed Gateway Clusters
• Embedded Derby Database (Ephemeral) Gateways

Custom Resources

• Gateway
• Repository
• L7Api
• L7Portal

Features

• Gateway Helm Chart feature parity (no sample mysql/hazelcast/influxdb/grafana deployments)
• Graphman Integration
• Git Integration for Graphman Repositories
  • Dynamic updates
  • Static (bootstrap) updates
• Dynamic Volumes for existing Kubernetes Configmaps/Secrets.
• Dynamic Volumes for CSI Secret Volumes.
• Application level port configuration
• Dedicated Service for access to Policy Manager/Gateway management services (when an external MySQL database is present).
• External Secrets
• OpenTelemetry Integration (check out the examples!)

External Secrets

A new configuration option for external secrets has been created. This allows you to reference existing Kubernetes secrets which are synced with the Gateway's Stored Passwords for use in things like JDBC connections or policy.

External providers can be configured with the external secrets operator.

app:
...
  externalSecrets:
    - name: database-credentials-gcp
      enabled: true
      description: GCP Database credentials
      variableReferencable: true
      auth:
        encryption:
          passphrase: 7layer
          existingSecret: ""
    - name: local-secret
      enabled: true
      description: local secret
      variableReferencable: true
      auth:
        encryption:
          passphrase: 7layer
          existingSecret: ""

Portal Integration (alpha)

The L7Portal controller is responsible for synchronizing Portal Managed APIs, the API Controller is responsible for applying those to target Gateway Deployments.

This integration handles CRUD on an individual API basis, the relationship between APIs and Gateways is deploymentTag.

There is a pre-configured example with an existing Portal Tenant containing 3 Portal APIs. To create your own update the l7Portal CR

1. Create the Portal Enrolment bundle

• kubectl create secret generic graphman-portal-bootstrap-bundle --from-file=./example/base/resources/secrets/bundles/portal-integration.json

1. Apply the portal gateway here

• kubectl apply -f ./example/gateway/portal-gateway.yaml

1. Apply the l7portal CR here

• kubectl apply -f ./config/samples/security_v1alpha1_l7portal.yaml

Under consideration

• OTK support (operator managed)
  • experimental options available
    • ephemeral gateway only
• Additional Custom Resources

Prerequisites

• Kubernetes v1.25+
• Gateway v10/11.x License
• Ingress Controller (You can also expose Gateway Services as L4 LoadBalancers)

Index

• Deploy the Layer7 Operator
  • Using Kubernetes CLI (kubectl)
    • OwnNamespace
    • All/Multiple Namespaces
  • Using OLM (Openshift)
• Create a Simple Gateway
• More Examples

Installation

There are currently two ways to deploy the Layer7 Gateway Operator. A Helm Chart will be available in the future.

Install with kubectl

Clone this repository to get started

git clone https://github.com/caapim/layer7-operator.git
cd layer7-operator

bundle.yaml contains all of the manifests that the Layer7 Operator requires.

OwnNamespace

By default the Operator manages the namespace that it is deployed into and does not create any cluster roles/role bindings.

kubectl apply -f deploy/bundle.yaml

All/Multiple Namespaces

You can also configure the Operator to watch all or multiple namespaces. This will create a namespace called layer7-operator-system. The default is all namespaces, you can update this by changing the following in deploy/cw-bundle.yaml

default (watches all namespaces)

env:
- name: WATCH_NAMESPACE
  value: ""

limit to specific namespaces

env:
- name: WATCH_NAMESPACE
  value: "ns1,ns2,ns3"

Once you have updated deploy/cw-bundle.yaml run the following command to install the Operator

kubectl apply -f deploy/cw-bundle.yaml

Install on OpenShift

The Layer7 Operator has not been published to any Operator Catalogs, you can still deploy it using the operator-sdk cli. The only supported install mode in OpenShift is OwnNamespace.

operator-sdk run bundle docker.io/layer7api/layer7-operator-bundle:v1.0.3 --install-mode OwnNamespace

Install using the Helm Chart

The Layer7 Operator Helm Charts are currently located in charts. The Layer7 Operator Chart requires cluster privileges to install and watches all namespaces by default

helm install layer7-operator ./charts/layer7-operator -n layer7-operator-system --create-namespace

Create a Simple Gateway

These steps will deploy a gateway with no additional configuration. This gateway deployment will run in ephemeral mode, without an external MySQL database. This is useful if you're new to the Layer7 API Gateway, Kubernetes Operators or you just want to make sure that the Layer7 Operator is up and running. More advanced configuration can be found here

1. Create a Kubernetes Secret with your Gateway license file

important: the file name should be license.xml

kubectl create secret generic gateway-license --from-file=/path/to/license.xml

1. Create a Gateway Custom Resource

kubectl apply -f - <<EOF
apiVersion: security.brcmlabs.com/v1
kind: Gateway
metadata:
  name: ssg
spec:
  version: "11.0.00_CR1"
  license:
    accept: true
    secretName: gateway-license
  app:
    replicas: 1
    image: docker.io/caapim/gateway:11.0.00_CR1
    management:
      username: admin
      password: 7layer
      cluster:
        password: 7layer
        hostname: gateway.brcmlabs.com
    service:
      # annotations:
      type: LoadBalancer
      ports:
      - name: https
        port: 8443
        targetPort: 8443
        protocol: TCP
      - name: management
        port: 9443
        targetPort: 9443
        protocol: TCP
EOF

1. Get the LoadBalancer Address

kubectl get svc

expected output

NAME  TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                         AGE
ssg   LoadBalancer   10.68.4.126   35.189.116.20   8443:31384/TCP,9443:31359/TCP   7m39s

if your output looks like this that means you don't have an External IP Provisioner in your Kubernetes Cluster. You can still access your Gateway using port-forward.

NAME  TYPE           CLUSTER-IP    EXTERNAL-IP     PORT(S)                         AGE
ssg   LoadBalancer   10.68.4.126   <PENDING>   8443:31384/TCP,9443:31359/TCP   7m39s

1. Sign into Policy Manager

username: admin
password: 7layer
gateway: 35.189.116.20

if you don't have an external ip

kubectl port-forward svc/ssg 8443

username: admin
password: 7layer
gateway: localhost

1. Remove the Gateway Resource

kubectl delete gateway ssg

Remove the Operator

if you installed the operator using kubectl

kubectl delete -k deploy/bundle.yaml|cw-bundle.yaml

if you installed the operator in Openshift

operator-sdk cleanup <operatorPackageName> [flags]