Managing CLI Profiles
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.
TOC
Convenient Configuration Management
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.
Platform and Session Management
ac login - Authenticate and configure access to ACP platforms
The 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:
- Authenticates against the ACP platform
- Discovers all accessible clusters within the platform
- Creates cluster and user entries in your kubeconfig
- Creates and activates a context:
- If
--clusteris specified: creates context for that specific cluster - If
--namespaceis specified: sets the namespace in the context - If no cluster is specified: defaults to the global cluster
- Context name follows pattern:
<session_name>/<cluster_name>
- If
ac logout - End platform sessions and clean up configuration
The logout command removes all session-related configuration entries including clusters, users, and contexts.
ac config get-sessions - List all configured ACP platform sessions
Example output:
This command displays:
- CURRENT: Indicates if the current context belongs to this session (marked with
*) - SESSION: Session name (user-defined during login)
- PLATFORM: Base platform URL
- USER: Authenticated username for the session
- CLUSTERS: Number of clusters available in this session
ac config use-session <session_name> - Switch between ACP platforms
This command intelligently selects or creates appropriate contexts based on your session and cluster requirements.
Daily Operations
ac config use-cluster <cluster_name> - Switch clusters within current session
This command finds or creates contexts for the specified cluster within your current platform session.
ac namespace - View current status and switch namespaces
Display current status:
Example output:
Switch namespace:
ac config sync - Synchronize platform configuration
The sync command refreshes your configuration with the latest information from ACP platforms, adding new clusters and updating credentials as needed.
Understanding ACP CLI Configuration Structure
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-Enhanced kubeconfig Structure
ACP CLI extends the standard kubeconfig format with ACP-specific metadata for enhanced platform integration:
Metadata Structure and Organization
ACP CLI uses extension metadata to organize and identify configuration entries:
Metadata-Based Identification
- Platform Identification: Uses
platformUrlto identify the parent platform - Session Association: Uses
sessionNameto group related clusters, users, and contexts - Global Cluster Detection: Uses
isGlobalfield to identify management clusters - User Credential Location: Matches
sessionNameandplatformUrlin user extensions
Naming Conventions
ACP CLI uses consistent naming conventions when creating new entries:
- Cluster entries:
acp:<session_name>:<cluster_name>(e.g.,acp:prod:global) - User entries:
acp:<session_name>:user(e.g.,acp:prod:user) - Context entries:
<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.
Manual Configuration of CLI Profiles
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:
- Custom context naming - Creating contexts that don't follow ACP CLI naming conventions
- Non-ACP environments - Managing traditional kubectl contexts alongside ACP sessions
- Complex multi-context scenarios - Advanced workflows requiring precise context control
- Troubleshooting configuration issues - Debugging or repairing configuration problems
Standard Configuration Commands
ACP CLI provides full compatibility with kubectl config subcommands:
Example Manual Operations
Create a custom context:
View current configuration:
Update context namespace:
Load and Merge Rules
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:
- If the
--configoption is set, then only that file is loaded. The flag is set once and no merging takes place. - If the
$KUBECONFIGenvironment 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. - Otherwise, the
~/.kube/configfile is used and no merging takes place.
- If the
-
The context to use is determined based on the first match in the following flow:
- The value of the
--contextoption. - The
current-contextvalue from the CLI config file. - An empty value is allowed at this stage.
- The value of the
-
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:
- The value of the
--userfor user name and--clusteroption for cluster name. - If the
--contextoption is present, then use the context's value. - An empty value is allowed at this stage.
- The value of the
-
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:
- The values of any of the following command-line options:
--server,--api-version,--certificate-authority,--insecure-skip-tls-verify - If cluster information and a value for the attribute is present, then use it.
- If you do not have a server location, then there is an error.
- The values of any of the following command-line options:
-
The 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--token
-
For any information that is still missing, default values are used and prompts are given for additional information.