Setting up the API
IBM Cloud Satellite shares the same application programming interface (API) as IBM Cloud Kubernetes Service and Red Hat OpenShift on IBM Cloud, so that you can use the same methods to consistently create and manage your Satellite resources.
About the API
The Satellite API automates the provisioning and management of IBM Cloud infrastructure resources for your clusters so that your apps have the compute, networking, and storage resources that they need to serve your users.
The API supports the different infrastructure providers that are available for you to create clusters and resources. The v2
API is designed to avoid breaking existing functionality when possible. However, make sure that you review
the following differences between the v1
and v2
API.
- API endpoint prefix
- v1 API:
https://containers.cloud.ibm.com/global/v1
- v2 API:
https://containers.cloud.ibm.com/global/v2
- API reference docs
- v1 API:
https://cloud.ibm.com/apidocs/kubernetes/containers-v1-v2
- v2 API:
https://cloud.ibm.com/apidocs/kubernetes/containers-v1-v2
- API architectural style
- v1 API: Representational state transfer (REST) that focuses on resources that you interact with through HTTP methods such as
GET
,POST
,PUT
,PATCH
, andDELETE
. - v2 API: Remote procedure calls (RPC) that focus on actions through only
GET
andPOST
HTTP methods. GET
responses- v1 API: The
GET
method for a collection of resources (such asGET v1/clusters
) returns the same details for each resource in the list as aGET
method for an individual resource (such asGET v1/clusters/{idOrName}
). - v2 API: To return responses faster, the v2
GET
method for a collection of resources (such asGET v2/clusters
) returns only a subset of information that is detailed in aGET
method for an individual resource (such asGET v2/clusters/{idOrName}
). Some list responses include a providers property to identify whether the returned item applies to classic or VPC infrastructure. For example, theGET zones
list returns some results such asmon01
that are available only in the classic infrastructure provider, while other results such asus-south-01
are available only in the VPC infrastructure provider. - Cluster, worker node, and worker-pool responses
- v1 API: Responses include only information that is specific to the classic infrastructure provider, such as the VLANs in
GET
cluster and worker responses. - v2 API: The information that is returned varies depending on the infrastructure provider. For such provider-specific responses, you can specify the provider in your request. For example, VPC clusters don't return VLAN information since they don't have VLANs. Instead, they return subnet and CIDR network information.
Working with API keys
To manage the IBM Cloud API keys that are associated with your user identity or the ones that you have access to manage for other users in the account, go to Manage > Access (IAM) > API keys in the IBM Cloud console.
On the IBM Cloud API keys page, you can create, edit, or delete IBM Cloud API keys for yourself, and you can manage all classic infrastructure API keys for users to which you are an ancestor in the user hierarchy. This means you can manage API keys for all users you invited to the account, or your child users invited to the account, and so on. In addition, if you are the account owner or a user with the required access to manage other user's API keys in the account, you can use the View filter to list and manage those API keys.
Required access for managing API keys
By default, you always have access to create your own API keys, and then update and delete them as needed. You also can manage your own classic infrastructure API key and any users' classic infrastructure API keys who you are an ancestor of in the classic infrastructure user hierarchy, meaning you invited the user or someone you invited to the account invited the user, and so on.
If the Restrict API key creation IAM account setting is enabled, then everyone in the account is blocked from creating API keys, including the account owner, unless they are assigned explicit access. For more information, see Restricting users from creating API keys.
If you are the account owner or a user with the required access, you can access other user's API keys or service ID API keys by using the View filter on the API keys page. You can edit or delete the API keys depending on your assigned access. You see only the filter options for the type of API keys that you have access to view and manage.
Filter Options | Displayed API Keys | Required Access | Allowed Actions |
---|---|---|---|
My IBM Cloud API keys | Your IBM Cloud API keys | No access required | View, create, edit, delete |
All IBM Cloud user API keys | All IBM Cloud API keys created by all users in the account | Administrator role on the IAM Identity service | View, edit, and delete |
All service ID API keys | All API keys created for service IDs in the account | Administrator role on the IAM Identity service | View, edit, and delete |
Classic infrastructure API keys | Your classic infrastructure API key and any classic infrastructure API keys for users who you are ancestor of in the user hierarchy | No access required other than being an ancestor in the user hierarchy | View details and delete |
Generating an IAM token
You can generate an IAM token by using either your IBM Cloud API key or a service ID's API key. The API key is a permanent credential that can be reused if you don't lose the API key value or delete the API key in the account. This process is also used if you are developing an application that needs to work with other IBM Cloud services. You must use a service ID API key to get an access token to be passed to each of the IBM Cloud services.
An access token is a temporary credential that expires after 1 hour at the latest. After the acquired token expires, you must generate a new token to continue calling IBM Cloud or service APIs, and you can perform only actions that are allowed
by your level of assigned access within all accounts. Use the response property expires_in
in the API response to identify the length of time that your specific access token is valid.
Passing an IBM Cloud IAM token to authenticate with a service's API
To retrieve an IAM access token, the API client must first invoke an IBM Cloud IAM API to authenticate and retrieve that token. The preferred way for IBM Cloud service API clients is to use an IBM Cloud API key to get an IAM access token. The IAM access token, which was implemented as a JSON Web Token, can be used for multiple invocations of IBM Cloud services that accept IAM access tokens as an authentication method. As IAM access tokens are digitally signed with asymmetric keys, IBM Cloud services can validate an IAM access token without invoking any external service. This dramatically improves the performance of invoking an API.
To authenticate with a service's API by using an access token, complete the following steps:
- First, create an IBM Cloud API key if you have not already.
- The next step for the API client is the retrieval of an IAM access token, as described in Getting an IAM token from an API key.
- From the response, extract the property
access_token
to get the IAM access token.expires_in
indicates the seconds until the IAM access tokenaccess_token
expires. Either use this relative value or the absolute time stampexpiration
based in UNIX time. - Send the IAM access token as described in RFC 6750, section 2.1. Authorization Request Header Field.
Review the following example:
- Use the HTTP header Authorization
- Prefix the IAM access token with the literal
Bearer eyJhbGciOiJSUzI1Ng...
- Add the prefixed IAM access token to the HTTP header:
Authorization: Bearer eyJhbGciOiJSUzI1Ng...
curl -H "Authorization: Bearer eyJhbGciOiJSUzI1Ng..."
import com.ibm.cloud.sdk.core.security.BearerTokenAuthenticator;
import <sdk_base_package>.ExampleService.v1.ExampleService;
...
String bearerToken = // ... obtain bearer token value ...
// Create the authenticator.
BearerTokenAuthenticator authenticator = new BearerTokenAuthenticator(bearerToken);
// Create the service instance.
ExampleService service = new ExampleService(authenticator);
// 'service' can now be used to invoke operations.
...
// Later, if your bearer token value expires, you can set a new one like this:
newToken = // ... obtain new bearer token value
authenticator.setBearerToken(newToken);
const ExampleServiceV1 = require('mysdk/example-service/v1');
const { BearerTokenAuthenticator } = require('mysdk/auth');
const authenticator = new BearerTokenAuthenticator({
bearerToken: '<access-token>',
});
const myService = new ExampleServiceV1({
authenticator,
});
...
// Later when the access token expires, the application must acquire
// a new access token, then set it on the authenticator.
// Subsequent request invocations will include the new access token.
authenticator.setBearerToken('<new-access-token>')
from ibm_cloud_sdk_core.authenticators import BearerTokenAuthenticator
authenticator = BearerTokenAuthenticator(<your_bearer_token>)
service = ExampleService(authenticator=authenticator)
# after getting a new access token...
service.get_authenticator().set_bearer_token('54321');
import {
"github.com/IBM/go-sdk-core/v5/core"
"<appropriate-git-repo-url>/exampleservicev1"
}
...
// Create the authenticator.
bearerToken := // ... obtain bearer token value ...
authenticator := &core.BearerTokenAuthenticator{
BearerToken: bearerToken,
}
// Create the service options struct.
options := &exampleservicev1.ExampleServiceV1Options{
Authenticator: authenticator,
}
// Construct the service instance.
service := exampleservicev1.NewExampleServiceV1(options)
// 'service' can now be used to invoke operations.
...
// Later, if your bearer token value expires, you can set a new one like this:
newToken := // ... obtain new bearer token value
authenticator.BearerToken = newToken
Use the same IAM access token for subsequent IBM Cloud service API calls to achieve the best performance and scalability.
Passing an IBM Cloud API key to authenticate with a service API
API clients can directly pass an IBM Cloud API key to the target service’s API. To do so, send the apikey
keyword as the user name and the IBM Cloud API key as the password by using basic authorization HTTP header to the target
service.
It is recommended that in all cases of passing an API key to a service API that you use an API key for a service ID or a user API key that is associated with a functional ID that is assigned only the level of access required to work with the particular service.
The target service API must introspect the IBM Cloud API key by using the IBM Cloud IAM service. The following graphic shows three API interactions. The IBM Cloud API key is passed to every target service’s API, so each target service must look up the IBM Cloud API key details by invoking IBM Cloud IAM.
Using an IBM Cloud API key is convenient, and it makes it easy to discover new APIs and quickly try out prototypes. This method requires you to send the IBM Cloud API key to the target service‘s API in a readable format, which unnecessarily compromises the API key. Additionally, as the target service’s API must always introspect the API key, this method is less performant and therefore not recommended for production work loads.
To authenticate with a service's API by using an API key, complete the following steps:
- First, create an IBM Cloud API key if you have not already.
- Send the IBM Cloud API key as defined in RFC 7617 as HTTP header “Authorization”. Use
apikey
as the user name, and the API key value as the password.
As an example, the following steps assume that the API key is 0a1A2b3B4c5C6d7D8e9E:
- Concatenate the user name
apikey
and the API key that is separated by a colon:apikey:0a1A2b3B4c5C6d7D8e9E
- Base64 encode the string:
base64("apikey:0a1A2b3B4c5C6d7D8e9E") => YXBpa2V5OjBhMUEyYjNCNGM1QzZkN0Q4ZTlF
- Set the HTTP header Authorization with schema Basic, for example
Authorization: Basic YXBpa2V5OjBhMUEyYjNCNGM1QzZkN0Q4ZTlF
. When you use the curl command, you can pass this with the parameter -u:
curl -u "apikey:<IBM Cloud API key value>"
import com.ibm.cloud.sdk.core.security.BasicAuthenticator;
import <sdk_base_package>.ExampleService.v1.ExampleService;
...
// Create the authenticator.
BasicAuthenticator authenticator = new BasicAuthenticator.Builder()
.username("myuser")
.password("mypassword")
.build();
// Create the service instance.
ExampleService service = new ExampleService(authenticator);
// 'service' can now be used to invoke operations.
from ibm_cloud_sdk_core.authenticators import BasicAuthenticator
authenticator = BasicAuthenticator(<your_username>, <your_password>)
service = ExampleService(authenticator=authenticator)
import {
"github.com/IBM/go-sdk-core/v5/core"
"<appropriate-git-repo-url>/exampleservicev1"
}
...
// Create the authenticator.
authenticator := &core.BasicAuthenticator{
Username: "myuser",
Password: "mypassword",
}
// Create the service options struct.
options := &exampleservicev1.ExampleServiceV1Options{
Authenticator: authenticator,
}
// Construct the service instance.
service := exampleservicev1.NewExampleServiceV1(options)
// 'service' can now be used to invoke operations.
The username is apikey
and the password is the api key itself.