A CLI configuration file allows you to configure different profiles, or contexts, for use with ACP CLI (ac). A context consists of user authentication and ACP platform server information associated with a nickname.
ACP CLI provides enhanced commands that make configuration management much easier than traditional kubeconfig manipulation. These commands are designed to work seamlessly with ACP's multi-cluster environment.
ac login - Authenticate and configure access to ACP platformsThe ac login command serves as the primary entry point for establishing connections to ACP platforms. It authenticates users and automatically configures all necessary kubeconfig entries.
The login process:
--cluster is specified: creates context for that specific cluster--namespace is specified: sets the namespace in the context<session_name>/<cluster_name>ac logout - End platform sessions and clean up configurationThe logout command removes all session-related configuration entries including clusters, users, and contexts.
ac config get-sessions - List all configured ACP platform sessionsExample output:
This command displays:
*)ac config use-session <session_name> - Switch between ACP platformsThis command intelligently selects or creates appropriate contexts based on your session and cluster requirements.
ac config use-cluster <cluster_name> - Switch clusters within current sessionThis command finds or creates contexts for the specified cluster within your current platform session.
ac namespace - View current status and switch namespacesDisplay current status:
Example output:
Switch namespace:
ac config sync - Synchronize platform configurationThe sync command refreshes your configuration with the latest information from ACP platforms, adding new clusters and updating credentials as needed.
ACP CLI stores all configuration information in the standard ~/.kube/config file, ensuring full compatibility with kubectl and other Kubernetes tools while adding ACP-specific enhancements.
ACP CLI extends the standard kubeconfig format with ACP-specific metadata for enhanced platform integration:
ACP CLI uses extension metadata to organize and identify configuration entries:
platformUrl to identify the parent platformsessionName to group related clusters, users, and contextsisGlobal field to identify management clusterssessionName and platformUrl in user extensionsACP CLI uses consistent naming conventions when creating new entries:
acp:<session_name>:<cluster_name> (e.g., acp:prod:global)acp:<session_name>:user (e.g., acp:prod:user)<session_name>/<cluster_name> (e.g., prod/global)The acp: prefix ensures ACP CLI-managed entries don't conflict with existing kubeconfig entries.
Users can manually rename these entries - ACP CLI uses metadata for identification, not names.
For advanced users who need precise control over configuration, ACP CLI supports all standard kubectl config commands for manual kubeconfig management.
Most users should use the convenient commands described above.
Manual configuration commands are useful for advanced scenarios:
ACP CLI provides full compatibility with kubectl config subcommands:
| Subcommand | Usage |
|---|---|
set-cluster | Sets a cluster entry in the CLI config file |
set-context | Sets a context entry in the CLI config file |
use-context | Sets the current context using the specified context name |
set | Sets an individual value in the CLI config file |
unset | Unsets individual values in the CLI config file |
view | Displays the merged CLI configuration currently in use |
Create a custom context:
View current configuration:
Update context namespace:
You can follow these rules when issuing CLI operations for the loading and merging order for the CLI configuration:
CLI config files are retrieved from your workstation, using the following hierarchy and merge rules:
--config option is set, then only that file is loaded. The flag is set once and no merging takes place.$KUBECONFIG environment variable is set, then it is used. The variable can be a list of paths, and if so the paths are merged together. When a value is modified, it is modified in the file that defines the stanza. When a value is created, it is created in the first file that exists. If no files in the chain exist, then it creates the last file in the list.~/.kube/config file is used and no merging takes place.The context to use is determined based on the first match in the following flow:
--context option.current-context value from the CLI config file.The user and cluster to use is determined. At this point, you may or may not have a context; they are built based on the first match in the following flow, which is run once for the user and once for the cluster:
--user for user name and --cluster option for cluster name.--context option is present, then use the context's value.The actual cluster information to use is determined. At this point, you may or may not have cluster information. Each piece of the cluster information is built based on the first match in the following flow:
--server, --api-version, --certificate-authority, --insecure-skip-tls-verifyThe actual user information to use is determined. Users are built using the same rules as clusters, except that you can only have one authentication technique per user; conflicting techniques cause the operation to fail. Command-line options take precedence over config file values. Valid command-line options are:
--auth-path--client-certificate--client-key--tokenFor any information that is still missing, default values are used and prompts are given for additional information.