Accessing clusters from automation tools

Use an IBM Cloud IAM API key or service ID to log in to a cluster from automated pipelines, CI/CD tools, or scripts that run non-interactively.

Using an API key to log in

An IAM API key is the recommended approach for automation and CI/CD pipelines.

  1. Create an API key and save the output — the key value cannot be retrieved again.
    ibmcloud iam api-key-create <name>
  2. Log in with the API key.
    ibmcloud login --apikey API_KEY
  3. Set the cluster context.
    ibmcloud oc cluster config -c CLUSTER_NAME_OR_ID
  4. Log in to the cluster.
    oc login -u apikey -p API_KEY [--server=PRIVATE_SERVICE_ENDPOINT]

Using a service ID to log in

Use a service ID when apps in other clusters or clouds need to access your cluster's services, or when you need credentials that are not tied to a specific user.

  1. Create a service ID.
    ibmcloud iam service-id-create CLUSTER_NAME-id --description "Service ID for cluster CLUSTER_NAME"
  2. Assign an IAM policy to the service ID.
    ibmcloud iam service-policy-create SERVICE_ID --service-name containers-kubernetes --roles ROLE --service-instance CLUSTER_ID
  3. Create an API key for the service ID.
    ibmcloud iam service-api-key-create CLUSTER_NAME-key SERVICE_ID
  4. Use the API key to log in by following the steps in Using an API key to log in.

Protecting clusters using context based restrictions

Private service endpoint allowlists are no longer supported. Migrate from private service endpoint allowlists to context based restrictions as soon as possible. For specific migration steps, see Migrating from a private service endpoint allowlist to context based restrictions (CBR).

Control access to your public and private service endpoints using context based restriction (CBR) rules.

After you grant users access to your cluster through IBM Cloud IAM, you can add a secondary layer of security by creating CBR rules for your cluster's public and private service endpoint. Only authorized requests to your cluster master that originate from subnets in the CBR rules will be allowed.

If you want to allow requests from a different VPC than the one your cluster is in, you must include the cloud service endpoint IP address for that VPC in the CBR rules.

For example, to access your cluster's private cloud service endpoint, you must connect to your IBM Cloud classic network or your VPC network through a VPN or IBM Cloud Direct Link. You can specify just the subnet for the VPN or Direct Link tunnel to your CBR rules so that only authorized users in your organization can access the private cloud service endpoint from that subnet.

Public CBR rules (if your cluster has a public service endpoint) can also help prevent users from accessing your cluster after their authorization is revoked. When a user leaves your organization, you remove their IBM Cloud IAM permissions that grant them access to the cluster. However, the user might have copied the admin kubeconfig file for a cluster, giving them access to that cluster. If you have a public CBR rule that only allows access to your cluster masters from known public subnets that your organization owns, then the user's attempted access from another public IP address will be blocked.

Worker node subnets are automatically added to and removed from the backend CBR implementation (but not the CBR rules/zones), so that worker nodes can always access the cluster master and users do not need to specifically add these to their own CBR rules.

To learn more about protecting your cluster with CBR rules, see Protecting cluster resources with context-based restrictions and Example context-based restrictions scenarios