Cloud Development Kit for Kubernetes (cdk8s) is a software development framework for defining Kubernetes applications and reusable abstractions using familiar programming languages and rich object-oriented APIs. cdk8s generates pure Kubernetes YAML — you can use cdk8s to define applications for any Kubernetes cluster running anywhere.

Recently the cdk8s team has expanded the capabilities of the “cdk8s import” command, simplifying the process to incorporate Helm charts. Providing a Helm Chart URL to the “cdk8s import” command will auto-generate a custom type-safe construct for you that represents the Helm Chart in question.

Let’s start by initializing a new cdk8s project in an empty directory:

mkdir cdk8simporthelm && cd cdk8simporthelm
cdk8s init typescript-app

You should see the following basic structure of a cdk8s application with the _constructs_ and _cdk8s_ libraries:

import { Construct } from 'constructs';
import { App, Chart, ChartProps } from 'cdk8s';
import { Redis, RedisArchitecture } from './imports/redis';

export class MyChart extends Chart {
  constructor(scope: Construct, id: string, props: ChartProps = {}) {
    super(scope, id, props);
    // define resources here
  }
}

const app = new App();
new MyChart(app, 'cdk8simporthelm');
app.synth();

Now let’s go ahead and import the Bitnami Redis chart:

cdk8s import helm:https://charts.bitnami.com/bitnami/redis@18.2.0

Moving back to our main.ts file we can now import the new Redis module that was generated in the previous step:

import { Construct } from 'constructs';
import { App, Chart, ChartProps } from 'cdk8s';
import { Redis, RedisArchitecture } from './imports/redis';

export class MyChart extends Chart {
  constructor(scope: Construct, id: string, props: ChartProps = {}) {
    super(scope, id, props);

    new Redis(this, 'Redis', {
      values: {
        architecture: RedisArchitecture.REPLICATION,     // <------- type safe property
      }
    });
  }
}

const app = new App();
new MyChart(app, 'cdk8simporthelm');
app.synth();

After we’re done adding anything else we need in addition to what’s above, let’s synthesize the k8s YAML manifest:

cdk8s synth

You should now have your manifest generated in the dist subfolder and you can run kubectl apply as you would with any other manifest.

You can find the source code repo for this blog post here: https://github.com/smallfriesdigital/cdk8s-helm-import

To access more info about Values Schema, Additional Values, Globals and Dependencies visit https://cdk8s.io/docs/latest/cli/import/#helm-charts

With the rising popularity of Function URLs, which are dedicated HTTP(S) endpoints for your Lambda function, we can avoid many of the complexities, costs and limitations associated with Amazon API Gateway. The downside is we also lose some of the nice features of an API Gateway that we get out of the box, one key feature being API routing based on method and path of an http event. This is where Middy, a Node.js middleware engine for AWS Lambda really comes in handy.

In particular, we can achieve nested http routing within our Lambdas by leveraging Middy’s http-router handler. Let’s start by cloning the starter project repo:

git clone https://github.com/AndrzejKomarnicki/awscdk-nodejsfunction-middy

Next let’s install the npm packages and run some AWS CDK CLI commands from the root working directory of our cloned repo.

npm install
cdk synth && cdk diff

By default AWS CDK CLI will check your environment variables for your AWS creds and region first, if not found it will default back to your AWS credentials and config files. You can of course also specify the AWS CLI profile of choice. For more info on how to setup environments for your Stack instance head over to https://docs.aws.amazon.com/cdk/v2/guide/environments.html.

Anyway, if everything checks out let’s proceed to deploy the Stack as part of our CDK app:

cdk deploy

After deployment, you should see output similar to below:

Next let’s dive into the Lambda function source code before we test the endpoints…

Open up index.ts from /services/node-lambda/

import middy from "@middy/core";
import jsonBodyParser from "@middy/http-json-body-parser";
import httpErrorHandler from "@middy/http-error-handler";
import httpSecurityHeaders from "@middy/http-security-headers";
import httpRouterHandler from "@middy/http-router";
import { APIGatewayProxyEventV2, APIGatewayProxyResultV2 } from "aws-lambda";
import { Logger, injectLambdaContext } from "@aws-lambda-powertools/logger";

const logger = new Logger({
  logLevel: "INFO",
  serviceName: "middy-example-api",
});

async function getHandler(
  event: APIGatewayProxyEventV2,
  context: any
): Promise<APIGatewayProxyResultV2> {
  // the returned response will be checked against the type `APIGatewayProxyResultV2`
  logger.info("This is a INFO log with some context");
  console.log("event 👉", event);
  return {
    statusCode: 200,
    body: JSON.stringify(`Hello from ${event.rawPath}`),
  };
}

async function postHandler(
  event: APIGatewayProxyEventV2,
  context: any
): Promise<APIGatewayProxyResultV2> {
  // the returned response will be checked against the type `APIGatewayProxyResultV2`
  logger.info("This is a INFO log with some context");
  console.log("event 👉", event);
  return {
    statusCode: 200,
    body: JSON.stringify(event.body),
  };
}

// routes served by httpRouterHandler middleware
// you can add more nested handlers for routes (method and path) as needed
const routes = [
  {
    method: "GET",
    path: "/user/{id}",
    handler: getHandler,
  },
  {
    method: "POST",
    path: "/user",
    handler: postHandler,
  },
];

export const handler = middy()
  .use(jsonBodyParser())
  .use(httpSecurityHeaders())
  .use(httpErrorHandler())
  .use(injectLambdaContext(logger)) // Change to (logger, { logEvent: true }) to log the incoming event
  .handler(httpRouterHandler(routes));

As you can tell we import httpRouterHandler from @middy/http-router, and we define two async node.js functions — getHandler() and postHandler(), which are referenced by the routes object as part of its handler property depending on http path and method in the http event.

Of course you can re-organize these nested Lambda handlers to be exported as modules instead of having everything in one monolithic index.ts file, this only serves as a starting point for demonstration purposes.

Let’s proceed to test our endpoints with the different paths and methods we defined. You can go back to the outputs generated by “CDK deploy” and test against both the Function URL and CloudFront URL.

GET method on /user/{userid}

POST method on /user

HashiCorp announced the general availability of Terraform CDK back in August 2022, and since then we’ve seen the arrival of several enhancements and new pre-built providers-many available through the Construct Hub. The beauty of CDKTF is that you can generate the code bindings for virtually any existing Terraform provider by simply using the cdktf cli and you can use the existing Terraform registry to look up a provider’s resource and argument reference.

The source code for this series can be found here: https://github.com/smallfriesdigital/cdktf-mongodbatlas-gcp.

Let’s dive head first into initializng a new cdktf project within our working dir that uses the GCP provider:

cdktf init --template=typescript --local --providers="google@~>4.0"

Next let’s add the pre-built MongoDB Atlas provider:

cdktf provider add mongodb/mongodbatlas

OK, so now let’s update MyStack in main.ts with the following CDKTF TypeScript code:

import { Construct } from "constructs";
import { App, TerraformStack, TerraformVariable } from "cdktf";
import { MongodbatlasProvider } from "@cdktf/provider-mongodbatlas/lib/provider";
import { Project } from "@cdktf/provider-mongodbatlas/lib/project";
import { Cluster } from "@cdktf/provider-mongodbatlas/lib/cluster";

class MyStack extends TerraformStack {
  constructor(scope: Construct, id: string) {
    super(scope, id);

    // define secure environment variables (won't end up in cdk.tf.json)
    const publicKey = new TerraformVariable(this, "publicKey", {
      type: "string",
      description: "MongoDB Atlas Org Public Key",
      sensitive: true,
    });

    const privateKey = new TerraformVariable(this, "privateKey", {
      type: "string",
      description: "MongoDB Atlas Org Private Key",
      sensitive: true,
    });

    const orgId = new TerraformVariable(this, "orgId", {
      type: "string",
      description: "MongoDB Atlas Org ID",
      sensitive: true,
    });

    // satisfy all the Atlas requirements before instantiating new cluster
    new MongodbatlasProvider(this, "Atlas", {
      publicKey: publicKey.value, // secret set via environment variable TF_VAR_publicKey
      privateKey: privateKey.value, // secret set via environment variable TF_VAR_privateKey
    });

    const atlasProject = new Project(this, "newProject", {
      name: "CDKTFProject1",
      orgId: orgId.value, // set via environment variable TF_VAR_orgId
    });

    // create cluster resource
    new Cluster(this, "newCluster1", {
      projectId: atlasProject.id,
      name: "atlasClusterCDK",
      clusterType: "REPLICASET",
      cloudBackup: false,
      mongoDbMajorVersion: "5.0",
      providerName: "TENANT",
      backingProviderName: "GCP",
      providerInstanceSizeName: "M0",
      providerRegionName: "CENTRAL_US",

      replicationSpecs: [
        {
          numShards: 1,
          regionsConfig: [
            {
              electableNodes: 3,
              priority: 7,
              readOnlyNodes: 0,
              regionName: "CENTRAL_US",
            },
          ],
        },
      ],
    });
  }
}

const app = new App();
new MyStack(app, "cdktf-gcp-mongodbatlas");
app.synth();

In this case we're using the free tier M0 Sandbox cluster, which is only recommended for development or testing purposes and doesn't support backups. Also keep in mind we are referencing the Atlas Region associated with the respective Google Cloud Region, not the GCP region name directly.
You can read more about that here: (https://www.mongodb.com/docs/atlas/reference/google-gcp/#std-label-google-gcp)

CDKTF Best Practices for handling secrets: use the TerraformVariable construct, Terraform uses the values in TerraformVariable directly at execution time, so CDKTF does not write them to the synthesized cdktf.json file. To pass a Terraform variable through environment variables, name the environment variable TF_VAR_NAME - 'NAME' being a placeholder for your variable name.

Environment variables that need to be set in the execution environment:

• TF_VAR_publicKey
• TF_VAR_privateKey
• TF_VAR_orgId

You can now feel free to run cdktf plan and cdktf deploy in order to get the base setup going, or instead choose to do it at the end once we wrap up all the other resource additions.

Let's go back and update the existing Cluster resource by assigning it to a constant in main.ts, then adding the admin database user to that cluster.

// create cluster resource
const atlasCluster = new Cluster(this, "newCluster1", {
  projectId: atlasProject.id,
  name: "atlasClusterCDK",
  clusterType: "REPLICASET",
  cloudBackup: false,
  mongoDbMajorVersion: "5.0",
  providerName: "TENANT",
  backingProviderName: "GCP",
  providerInstanceSizeName: "M0",
  providerRegionName: "CENTRAL_US",

  replicationSpecs: [
    {
      numShards: 1,
      regionsConfig: [
        {
          electableNodes: 3,
          priority: 7,
          readOnlyNodes: 0,
          regionName: "CENTRAL_US",
        },
      ],
    },
  ],
});

const adminPassword = new TerraformVariable(this, "adminPassword", {
  type: "string",
  description: "MongoDB Atlas Cluster DB Admin",
  sensitive: true,
});

// add admin user to cluster
new DatabaseUser(this, "adminUser", {
  username: "cdktf-adminuser",
  password: adminPassword.value, // secret set via environment variable TF_VAR_adminPassword
  projectId: atlasProject.id,
  authDatabaseName: "admin",
  roles: [
    {
      roleName: "readAnyDatabase",
      databaseName: "admin",
    },
  ],
  scopes: [
    {
      name: atlasCluster.name,
      type: "CLUSTER",
    },
  ],
});

Environment variables that need to be set in the execution environment:

• TF_VAR_adminPassword

Finally, let's add the remaining network access piece to our stack in main.ts:

const userNetwork = new TerraformVariable(this, "userNetwork", {
  type: "string",
  description: "MongoDB Atlas Project IP access",
  sensitive: false,
});

new ProjectIpAccessList(this, "projectnetworkAccess", {
  projectId: atlasProject.id,
  cidrBlock: userNetwork.value, // secret set via environment variable TF_VAR_userNetwork
});

Last but not least, define the one remaining env variable with your network CIDR.

Environment variables that need to be set in the execution environment:

• TF_VAR_userNetwork

cdktf plan
cdktf deploy

And voila! We are now ready to start developing against our MongoDB Atlas cluster from our machine. Bon coding.

In this article we’re going to be using curl, kubectl proxy and the K8s API to answer the following questions:

• Which namespaces are available in your config?
• Which pods have been started in the kube-system namespace?
• Which objects are available in the API v1 spec?
• Request a full specification of an nginx pod

If you’re running minikube or you are on a k8s node, you can check if kubectl proxy is running with ps axu | grep proxy otherwise just head straight to kubectl proxy --port=8001 and in a new shell type curl localhost:8001 which will show generic information about everything that is exposed. For instance curl localhost:8001/version will expose all the version info about your current cluster, in my case it shows the following:

{
"major": "1",
"minor": "10+",
"gitVersion": "v1.10.3-eks",
"gitCommit": "58c199a59046dbf0a13a387d3491a39213be53df",
"gitTreeState": "clean",
"buildDate": "2018-09-21T21:00:04Z",
"goVersion": "go1.9.3",
"compiler": "gc",
"platform": "linux/amd64"
}

From this data you can clearly tell that I am running my cluster on Amazon EKS which is a managed Kubernetes service from AWS, while the version of K8s is 1.10.3 (at the time of this writing the latest supported version on EKS).

Now on to the really interesting stuff…let’s take a look at all of our namespaces via curl localhost:8001/api/v1/namespaces | grep -A 2 name

You’ll see something more less like this (along with whatever other namespaces you created):

--
"name": "default",
"selfLink": "/api/v1/namespaces/default",
"uid": "d651faaa-a092-11e8-9b00-0a222b0de108",
"resourceVersion": "4",
--
"name": "kube-public",
"selfLink": "/api/v1/namespaces/kube-public",
"uid": "d8bc55f7-a092-11e8-9b00-0a222b0de108",
"resourceVersion": "16",
--
"name": "kube-system",
"selfLink": "/api/v1/namespaces/kube-system",
"uid": "d8bb77d6-a092-11e8-9b00-0a222b0de108",
"resourceVersion": "6665028",
--

Now let’s see what pods are started in the kube-system namespace with the following command: curl localhost:8001/api/v1/namespaces/kube-system/pods | grep -A 2 metadata

--
"metadata": {
"name": "kube-proxy-nkbhg",
"generateName": "kube-proxy-",
--
"metadata": {
"name": "kubernetes-dashboard-7d5dcdb6d9-xlk9t",
"generateName": "kubernetes-dashboard-7d5dcdb6d9-",
--
"metadata": {
"name": "monitoring-influxdb-cc95575b9-4nsnh",
"generateName": "monitoring-influxdb-cc95575b9-",
--
"metadata": {
"name": "my-nginx-77f56b88c8-6n6kv",
"generateName": "my-nginx-77f56b88c8-",
--

You should see your pods displayed in a format as per above (you should also see kube-dns, and whatever other stuff you’ve loaded in there). If you want detailed info for all the pods you can use:

curl localhost:8001/api/v1/namespaces/kube-system/pods | less

Exploring the different endpoints in the k8s API and how they are organized, including what objects and parameters are available, gives you a good idea as to how Kubernetes itself is internally structured and organized as well.

Now the next question was, which objects are available in the API v1 specification? That’s an easy one, if we take everything out and just use this:

curl localhost:8001/api/v1/

We get the object specification along with the name, kind, and verb.

Here’s an example from the output:

{
 "name": "services",
 "singularName": "",
 "namespaced": true,
 "kind": "Service",
 "verbs": [
 "create",
 "delete",
 "get",
 "list",
 "patch",
 "update",
 "watch"
 ],
 "shortNames": [
 "svc"
 ],
 "categories": [
 "all"
 ]
},

If you use curl localhost:8001/api/v1/ | grep name | less you can also see bindings, componentstatuses, configmaps, endpoints, events, and so on…

Now on to the last question, knowing what namespace you have deployed your nginx pod into and having retrieved the nginx pod name (or whatever other pod you want to explore) let’s take a look at it’s K8s API endpoint, which in my case is:

curl localhost:8001/api/v1/namespaces/kube-system/pods/my-nginx-77f56b88c8-6n6kv

{
 "kind": "Pod",
 "apiVersion": "v1",
 "metadata": {
  "name": "my-nginx-77f56b88c8-6n6kv",
  "generateName": "my-nginx-77f56b88c8-",
  "namespace": "kube-system",
  "selfLink": "/api/v1/namespaces/kube-system/pods/my-nginx-77f56b88c8-6n6kv",
  "uid": "55c120c2-d865-11e8-a61b-125b96951d82",
  "resourceVersion": "10649474",
  "creationTimestamp": "2018-10-25T14:50:37Z",
  "labels": {
   "pod-template-hash": "3391264474",
   "run": "my-nginx"
 },
 "ownerReferences": [
   {
    "apiVersion": "extensions/v1beta1",
    "kind": "ReplicaSet",
    "name": "my-nginx-77f56b88c8",
    "uid": "55bde0ea-d865-11e8-a61b-125b96951d82",
    "controller": true,
    "blockOwnerDeletion": true
   }
  ]
 },
 "spec": {
   "volumes": [
     {
       "name": "default-token-9qxrs",
       "secret": {
         "secretName": "default-token-9qxrs",
         "defaultMode": 420
       }
      }
    ],
    "containers": [
     {
       "name": "my-nginx",
       "image": "nginx",
       "ports": [ 
        {
           "containerPort": 80,
           "protocol": "TCP"
        }
      ],
      "resources": {
     
      },  
      "volumeMounts": [
       {
         "name": "default-token-9qxrs",
         "readOnly": true,
         "mountPath": "/var/run/secrets/kubernetes.io/serviceaccount"
       }
     ],
     "terminationMessagePath": "/dev/termination-log",
     "terminationMessagePolicy": "File",
     "imagePullPolicy": "Always"
    }
  ],
  "restartPolicy": "Always",
  "terminationGracePeriodSeconds": 30,
  "dnsPolicy": "ClusterFirst",
  "serviceAccountName": "default",
  "serviceAccount": "default",
  "nodeName": "ip-10-0-1-112.ec2.internal",
  "securityContext": {

  },
  "schedulerName": "default-scheduler",
  "tolerations": [
    {
      "key": "node.kubernetes.io/not-ready",
      "operator": "Exists",
      "effect": "NoExecute",
      "tolerationSeconds": 300
    },
    {
      "key": "node.kubernetes.io/unreachable",
      "operator": "Exists",
      "effect": "NoExecute",
      "tolerationSeconds": 300
    }
  ]
 },
 "status": {
  "phase": "Running",
  "conditions": [
    {
      "type": "Initialized",
      "status": "True",
      "lastProbeTime": null,
      "lastTransitionTime": "2018-10-25T14:50:37Z"
    },
    {
      "type": "Ready",
      "status": "True",
      "lastProbeTime": null,
      "lastTransitionTime": "2018-10-25T14:50:43Z"
    },
    {
      "type": "PodScheduled",
      "status": "True",
      "lastProbeTime": null,
      "lastTransitionTime": "2018-10-25T14:50:37Z"
    }
   ],
   "hostIP": "10.0.1.112",
   "podIP": "10.0.1.232",
   "startTime": "2018-10-25T14:50:37Z",
   "containerStatuses": [
    {
      "name": "my-nginx",
      "state": {
      "running": {
        "startedAt": "2018-10-25T14:50:43Z"
      }
    },
    "lastState": {

    },
    "ready": true,
    "restartCount": 0,
    "image": "nginx:latest",
    "imageID": "docker-pullable://nginx@sha256:b73f527d86e3461fd652f62cf47e7b375196063bbbd503e853af5be16597cb2e",
   "containerID":
"docker://9baf63301474ce5cddb37bd89c77785731221fedb1fb6d27e7a12c57c942f550"
   }
  ],
  "qosClass": "BestEffort"}
 }
}

So that concludes the scope of our journey, I hope you found it informative and now have a good idea as to how to navigate and query the Kubernetes API and are able to see how essential that practice can become especially when developing Kubernetes Operators and other Kubernetes Native applications or functions.

Many people have surely heard about JSON (JavaScript Object Notation), the ubiquitous markup format for data-interchange, and some spectrum of those individuals have undoubtably also heard about JWT (JSON Web Token), which is a very useful open standard for securely transmitting data between parties in a self-contained way via JSON objects. Long story short, the token is comprised of a header, payload and secret and can be sent through a URL, POST or inside an HTTP header.

Say for instance you are developing a MEAN Stack-based Web App and want to make sure that only authenticated or logged-in users can post messages, you could for instance use JWT enforcement to protect all Expressjs routes except for:

router.get(‘/’, function (req, res, next) {}) 

The ExpressJS router.use() method will allow you to execute a callback for every request other than the one above. The goal is to check if the client/browser is sending us a valid token. Given we are creating the token on the server and we know the logic behind the token, including the secret, we can easily validate the incoming token.

Assuming you’ve already installed the jsonwebtoken package, and imported it via require(‘jsonwebtoken’) you can take the following approach:

router.use('/', function(req, res, next) {
    jwt.verify(req.query.token, 'secret', function(err, decoded) {
        if (err) {
            return res.status(401).json({
                title: 'Authentication failed',
                error: err
            });
        }
        next();
     })
});

jwt.verify(req.query.token) validates the query parameters for the token, and the ‘secret’ has to match the secret when the token is created. The callback is immediately passed with either an error or a decoded token. If we get an error it either means the token is expired or was never valid to begin with.

Happy JWTing!