datagov-brokerpak-eks

Why this project

This is a cloud-service-broker plugin that makes AWS EKS brokerable via the Open Service Broker API (compatible with Cloud Foundry and Kubernetes), using Terraform.

Making EKS brokerable has two drivers:

1. Some workloads don't work as an app/in a PaaS. Teams can broker a k8s "sidecar" and deploy just those parts, while retaining use of the PaaS and avoiding interaction with the IaaS.
2. Further brokerpaks can expose other services easily, using this brokerpak as a base. (Here's a companion brokerpak that uses the Cloud Foundry Terraform provider to spin up a k8s instance via this broker, then deploys a Helm chart into it.)

For more information about the brokerpak concept, here's a 5-minute lightning talk from the 2019 Cloud Foundry Summit. You may also want to check out the brokerpak introduction and specification docs.

Huge props go to @josephlewis42 of Google for publishing and publicizing the brokerpak concept, and to the Pivotal team running with the concept!

Features/components

Each brokered AWS EKS provides:

• Kubernetes cluster spanning multiple AZs (AWS VPC)
• CIS-hardened managed nodes (GSA ISE, AWS EC2)
• Automated TLS configuration and 80->443 redirect (AWS Certificate Manager)
• Automated DNS and DNSSEC configuration for the cluster and workloads with ExternalDNS (AWS Route 53)
• Automated twice-hourly scanning and daily patching of nodes (AWS Inspector and AWS SSM)
• Via Starboard (docs)
  • Automated vulnerability scanning for Kubernetes workloads
  • Automated configuration audits for Kubernetes resources with predefined rules or custom Open Policy Agent (OPA) policies
  • Automated node scanning and compliance checks with CIS Benchmarks published by the Center for Internet Security (CIS)
  • Automated compliance report - NSA, CISA Kubernetes Hardening Kubernetes Guidance v1.0
  • Penetration test results for the cluster
• Control plane and workload logging with fluent-bit (AWS CloudWatch)
• A single Load Balancer per cluster (AWS Network Load Balancer)
• IaaS-independent deployments (using )nginx ingress controller)
• Dynamic persistent Volumes (AWS EBS and AWS EBS-CSI)
• Network Policy support with default-deny egress (AWS VPC-CNI and Calico)
• Auto-scaling (Karpenter)
• ZooKeeper CRDs ready for managing Apache ZooKeeper clusters
• Solr CRDs for managing SolrCloud instances
• Each binding generates a unique namespace-limited credential

Development Prerequisites

1. Docker Desktop (for Mac or Windows) or Docker Engine (for Linux) is used for building, serving, and testing the brokerpak.

2. Access to the GitHub Container Registry. (We are working on making the necessary container image publicly accessible; this step should not be necessary in future.)

3. make is used for executing docker commands in a meaningful build cycle.

4. AWS account credentials (as environment variables) are used for actual service provisioning. The corresponding user must have at least the permissions described in permission-policies.tf. Set at least these variables:

   • AWS_ACCESS_KEY_ID
   • AWS_SECRET_ACCESS_KEY
   • AWS_DEFAULT_REGION

Developing the brokerpak

Run the make command by itself for information on the various targets that are available. Notable targets are described below

$ make
clean      Bring down the broker service if it's up, clean out the database, and remove created images
build      Build the brokerpak(s) and create a docker image for testing it/them
up         Run the broker service with the brokerpak configured. The broker listens on `0.0.0.0:8080`. curl http://127.0.0.1:8080 or visit it in your browser.
test       Execute the brokerpak examples against the running broker
down       Bring the cloud-service-broker service down
all        Clean and rebuild, then bring up the server, run the examples, and bring the system down
help       This help

Running the brokerpak

Run

make build up

The broker will start and listen on 0.0.0.0:8080. You test that it's responding by running:

curl -i -H "X-Broker-API-Version: 2.16" http://user:pass@127.0.0.1:8080/v2/catalog

In response you will see a YAML description of the services and plans available from the brokerpak.

(Note that the X-Broker-API-version header is required by the OSBAPI specification. The broker will reject requests that don't include the header with 412 Precondition Failed, and browsers will show that status as Not Authorized.)

You can also inspect auto-generated documentation for the brokerpak's offerings by visiting http://127.0.0.1:8080/docs in your browser.

Testing the brokerpak (while it's running)

Run

make test

The examples specified by the brokerpak will be invoked for end-to-end testing of the brokerpak's service offerings.

You can also manually interact with the broker using the cloud-service-broker client sub-command or the eden OSBAPI client

Shutting the brokerpak down

Run

make down

The broker will be stopped.

Cleaning out the current state

Run

make clean

The built brokerpak files will be removed.

Cleaning up a botched service instance

You might end up in a situation where the broker is failing to cleanup resources that it has provisioned or bound. When that happens, follow this procedure.

Contributing

Check out the list of open issues for areas where you can contribute.

See CONTRIBUTING for additional information.

Public domain

This project is in the worldwide public domain. As stated in CONTRIBUTING:

This project is in the public domain within the United States, and copyright and related rights in the work worldwide are waived through the CC0 1.0 Universal public domain dedication.

All contributions to this project will be released under the CC0 dedication. By submitting a pull request, you are agreeing to comply with this waiver of copyright interest.