timroster

Creating Let's Encrypt certificates for IBM free Kubernetes clusters

The IBM Kubernetes service free clusters consist of a single worker node with 2 CPU and 4 GB of memory for experimenting with Kubernetes. Unlike the fee-based service, these clusters do not include capabilities for application load balancing using ingress out-of-the-box. However, if you manage a DNS domain (any provider will suffice) and can add an A record, it's possible for you to configure your own ingress that can provide http and https session termination for your containerized applications. Getting a TLS-enabled website or simply an external REST API couldn't be easier!

Prerequisites

• Free IBM Kubernetes Cluster (IKS) - upgrade your account from Lite plan to create one. In the example commands, we'll assume that this cluster is named mycluster
• kubectl - match your cluster API version (as of 12/5/20 - this is ~1.18.12)
• helm v3
• DNS domain that you can edit to configure

timroster

Requesting TLS certificates on Red Hat OpenShift using the cert-manager operator

OpenShift Container Platform typically supports edge-terminated TLS applications in a simple way for application developers through the route resource. This is accomplished through a wildcard certificate which will usually take a form like *.apps.cluster.domain.example.com. By default when exposing a service in OpenShift, a hostname is created by combining the service name (such as console) with a project (like openshift-console) to create a FQDN for a host, resulting in a host name like console-openshift-console.apps.cluster.domain.example.com. This just "works" due to the cluster wildcard certificate.

However, it is possible to manage custom certificates for use with OpenShift routes or Kubernetes ingress resources. The Cert-Manager CNCF project provides a handy tool to request custom TLS certificates for OpenShift, or any other Kubernetes platform. This gist will walk through setting

amitpj

Accessing a ROKS (Red Hat OpenShift on IBM Cloud) cluster using IBM IAM and IBM Kubernetes Service APIs

1. Retrieve IBM Cloud IAM <access_token> and <refresh_token> using the API key

curl -X POST -H "Authorization: Basic Yng6Yng=" -H "Content-Type: application/x-www-form-urlencoded" -d "grant_type=urn:ibm:params:oauth:grant-type:apikey&apikey=<APIKey>" "https://iam.cloud.ibm.com/identity/token"

The string "Yng6Yng=" is nothing but base64 encoded "bx" credentials.

Look for <access_token> and <refresh_token> in JSON output as shown below:

timroster

Self-service identity federation to an IBM Cloud Account with Okta

Although there is generic SAML identity integration examples provided in the AppID documentation, how to specifically configure a particular identity provider in a step-by-step manner can be non-trivial, especially for SAML. In general the approach is to configure SAML identity providers to work with App ID by providing metadata from App ID to your identity provider, and metadata from your identity provider to App ID.

This quick guide will provide tips on configuring access to Okta managed identities to an IBM Cloud Account by performing the following steps:

1. Adding an IBM Cloud Access Group with a policy for the users
2. Add an IBM AppID service instance (lite plan used in the case)
3. [Configure a SAML application in Okta](#configure-a-saml-a