# Ansible Satellite Authentication

The CMDB-360 Ansible Satellite allows you to orchestrate the deployment and management of cloud and on-premise assets. In order to achieve this, authentication to systems must be established. This document discusses different authentications and permissions from each cloud and also ssh key pairs

# Ansible Access

Access to assets that are managed by CMDB360 is handled by authentication data stored in your CMDB-360 vault credential files. The data in the encrypted vault filess depends on the access level desired and the cloud provider. There are two levels of access to assets. Cloud level (using only REST APIs) and Machine level using ssh, winrm or ssm.

For more information on vaults, see:

https://docs.cmdb360.com/docs/Satellites/Ansible-satellite/Vault/VaultOverview

# Cloud level access

Cloud level access requires authentication for the REST API calls. Typically this is an account identifier along with a client id and password. Once this access is set up, the Ansible Satellite can manage cloud assets. Actions like stopping/starting a VM or creating, destroying and modifying VMs or network assets can be allowed. Permissions can be managed to provide each user or group of users the proper access to specific assets.

Details on Cloud Authentication is below

# AWS Access Key

AWS uses Access Keys to control access to its accounts. AWS access keys are credentials consisting of an Access Key ID and a Secret Access Key, used to authenticate programmatic requests to AWS services via the CLI, SDKs, or API

access_key_id: AKIAS2CIS3YQCV6TXXXX access_key_secret: PXo006I0G89algWGlmpVLQk54hmlwBXXXXX/Di5F aws_region: us-east-2

# Azure Service Principal

Azure provides service principals to handle access to cloud assets. An Azure service principal is a security identity (non-human account) created for applications, hosted services, and automated tools to access specific Azure resources securely. It acts as a local representation of a global app object within a Microsoft Entra ID (Azure AD) tenant, allowing apps to authenticate and perform automated tasks without needing a human user login. To see more information on setting up a service principal, see:

https://docs.cmdb360.com/docs/Satellites/Azure-satellite/ConfigureAzAccess/ConfigureAzAccess

The Service Principal information (example below)

Tenant ID: 7c873309-xxxx-xxxx-xxxx-2ede6b84xxxx
Subscription ID: 227f6363-xxxx-xxxx-xxxx-398fe78exxxx
Client ID(appId): e190811c-xxx-xxxx-xxxx-fede365fxxxx
Client Secret(password):  MpMxxxxzCkiq7EXxxxxxwst2axxxxSDoXnk2xxxx

# Oracle Cloud Instance Principal

OCI provides user API keys to handle access to cloud assets. OCI API keys are an Identity and Access Management (IAM) capability in Oracle Cloud that allow applications to securely call OCI public services (REST APIs) without storing user credentials or configuration files on the instance. For more information on OCI Access, see:

https://docs.cmdb360.com/docs/Satellites/OCI-satellite/ConfigureOciAccess/ConfigureOciAccess

Example OCI API key data. Addtionally a private key file will be created and used

user=ocid1.user.oc1..aaaaaaaajpqggxldnhksjjmrh3sa5r3pbj3zrxxxxxxxxxxxxxxxxxxxxxxx
fingerprint=fb:26:4a:74:d6:57:ef:f4:xx:xx:xx:xx:xx:xx:xx:xx
tenancy=ocid1.tenancy.oc1..aaaaaaaa6dd7wklkedew2jozafzipccxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
region=us-phoenix-1
pass_phrase=password123 <- only if needed if private key has a password assocaited with it

# Machine level access

Ansible uses ssh to provide Machine level access to Linux machines and WinRM for Windows. Machine level access allow you to configure your device or run commands on the device. In order to create an ssh connection, the public key of a matching private key pair must be in the ./ssh/authorized_keys file of the user that is creating the connection. The private key is then provided as authentication.

# SSH Private Key

Ansible uses private keys to authenticate ssh connections to devices. In order to create an ssh connection, the public key of a matching private key pair must be in the ./ssh/authorized_keys file of the user that is creating the connection. The private key is then provided as authentication. CMDB360 uses RSA keys that are stored in a cloud vault to create the ssh connection for Ansible machine level access. Example RSA key format is below.

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEA5ZekAWtvAAoB2z/wGVvhy3u0XBRL7ap+XkHyrix9XVvI4Crp2tpF
.....
gOIIU+kkOqJ1F3LsoBGOMg6FQyjZC7xHYl0rT9qETA2iiTYeNrz/9/oy49KxFuPo2hqAwC
o7ceY41obxxxxxxxxxxxxxoY5UGLS3YJ02WQ2rTnYhGFvOLlT/ImQHx57CAn2l+q2J0ML4a
2iZJxeQ6lMQGkAAAAacm9vdEBhbnNpYmxlLXNhdGVxxxxxxxxxxxxx
-----END OPENSSH PRIVATE KEY-----

# WinRM

Ansible uses WinRM and one of several transport protocol options to authenticate to Windows. Each will need username and password for the Windows machine or AD account to be provided. Choose the appropriate one for your setup. Below is a table of the authentication options:

# AWS SSM (System Manager)

AWS provides an Ansible connection using System Manager to connect to your VMs without the need for SSH keys. The SSM agent comes pre-installed on AWS compute images. Your EC2 machines must be given correct role (typically AmazonSSMManagedInstanceCore) to access SSM as well as your user having the proper permissions for what you are trying to modify (for example, AmazonSSMFullAccess and AmazonEC2FullAccess).