Target Discovery, Credentials, and Supply Chain Management
Targets are the sources of supply chain data, and credentials are how mediation reads them. Expect questions on target setup, credential models, and how discovered entities are stitched into one graph.
Adding targets
- The flow is: choose the target type, supply address/port and credentials, Validate, then Add.
- Credentials should be least-privilege read-only; write permission is only needed where Turbonomic must execute actions through that target.
- Typical credential models: vCenter user/password, AWS access key or cross-account IAM role, Azure service principal, GCP service account JSON, Kubernetes service account token or kubeconfig, database and storage admin accounts.
- Status is Validated or Validation failed. Probes run on an interval, so discovery is never instantaneous.
Supply chain
- A single graph: Business Application, service, workload (VM or pod), host or node, cluster, datastore, storage array, SAN switch. Cloud adds account, region, and zone layers.
- Stitching depends on available data: a VM reaches its array only when datastore-to-LUN mapping can be resolved through a storage target or vCenter correlation.
- Kubernetes clusters are discovered through kubeturbo, which can be namespace-scoped.
Worked example
A newly added vCenter shows hosts and VMs, but storage actions never appear. Reasoning: the datastore exists but nothing links it to an array, so no storage seller exists in the market. Add the storage target, or fix zoning and LUN masking, so the topology processor can stitch datastore to volume. Policy is not the cause.
Traps
Using an admin account to be safe (breaks least privilege and audit); assuming a validated target means everything is already discovered; ignoring namespace scoping on Kubernetes targets.