An API-based pattern for accessing a Red Hat OpenShift cluster on IBM Cloud (ROKS)

api_roks.md

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:

{
   "access_token":"<access_token>",
   "refresh_token":"<refresh_token>",
   "ims_user_id":123,
   "token_type":"Bearer",
   "expires_in":1200,
   "expiration":1633975642,
   "refresh_token_expiration":1634060845,
   "scope":"ibm openid"
}

2. Retrieve the <api_server> of the cluster

curl -X POST -H "Authorization: Bearer <access_token>" -H "X-Auth-Refresh-Token: <refresh_token>" -H "Content-Type: application/json" -d "{\"cluster\": \"<clusterNameOrID>\"}" "https://containers.cloud.ibm.com/global/v2/applyRBACAndGetKubeconfig"

In addition to retrieving kubeconfig JSON containing the <api_server>, this API also syncs RBAC (Role-Based Access Control) information from IBM IAM to the cluster as suggested by name of the API. Without this sync, step 4 below fails with an error.

Look for "server" value in JSON output of the API as shown below:

{
   "kind":"Config",
   "apiVersion":"v1",
   "preferences":{},
   "clusters":[
      {
         "name":"xyz",
         "cluster":{
            "server":"<api_server>"
         }
      }
   ],
   "users":[],
   "contexts":[
      {
         "name":"xyz",
         "context":{
            "cluster":"xyz",
            "user":"",
            "namespace":"default"
         }
      }
   ],
   "current-context":"xyz"
}

3. Retrieve the <authorization_endpoint> of the cluster

curl "<api_server>/.well-known/oauth-authorization-server"

Look for "authorization_endpoint" value in JSON output of the API as shown below:

{
"issuer": "abc",
"authorization_endpoint": "<authorization_endpoint>",
"token_endpoint": "xyz",
"scopes_supported": [
.
.
 ],
.
.
}

4. Retrieve the <openshift_token>

curl -u "apikey:<APIKey>" -H "X-CSRF-Token: a" "<authorization_endpoint>?client_id=openshift-challenging-client&response_type=token" -v

Look for <openshift_token> in the Location response as show below:

< HTTP/1.1 302 Found
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Expires: 0
< Expires: Fri, 01 Jan 1990 00:00:00 GMT
< Location: <token_endpoint>/implicit#access_token=<openshift_token>&expires_in=86400&scope=user%3Afull&token_type=Bearer
< Pragma: no-cache
.
.

5. Finally, use the <api_server> and <openshift_token> to run either kubectl command or OpenShift API

kubectl --server "<api_server>" --token "<openshift_token>" get namespaces

OR

curl -H "Authorization: Bearer <openshift_token>" "<api_server>/api/v1/namespaces"

Reference documentation:

IBM:

https://cloud.ibm.com/docs/openshift?topic=openshift-access_cluster#access_automation

https://containers.cloud.ibm.com/global/swagger-global-api/

Red Hat:

https://docs.openshift.com/container-platform/4.6/authentication/understanding-authentication.html