One of the new features we added in Red Hat Ansible Tower 3.2 was support for custom credentials. The idea of custom credentials is pretty simple. In addition to the built-in credentials supported by Ansible Tower such as SSH keys, username/password combos, or cloud provider credentials, we now let the user define their own credentials for storing securely in Ansible Tower and exposing to playbooks.
However, this simplicity belies real power, opening up many new ways to automate. Let's dive into the details.
HOW CUSTOM CREDENTIALS WORK
To set up a custom credential, first you must define the custom credential Type.
Credential types consist of two key concepts - "inputs" and "injectors".
Inputs define the value types that are used for this credential - such as a username, a password, a token, or any other identifier that's part of the credential.
Injectors describe how these credentials are exposed for Ansible to use - this can be Ansible extra variables, environment variables, or templated file content.
Once you've defined a new Credential Type, you can then create any number of credentials that use that type. We'll go through examples to shed light on how this can be used to automate easier and in more ways.
CUSTOM CREDENTIALS - A SIMPLE EXAMPLE
We will start with a simple task - registering your Red Hat Enterprise Linux machines.
Even if you're opening up provisioning to your whole organization, you want to
make sure they're on the right account so they can be properly managed and tracked...
without necessarily exposing the password to your users.
To do this, we'll create a new Custom Credential type - Red Hat Subscription Manager.
Let's dig in more on the "input" and "injector" settings. Both the input and injector
definitions can be provided in either JSON or YAML format. We'll use YAML here for readability.
This Red Hat Subscription Manager consists of a username and password. We'll define the
inputs like this:
fields:
- type: string
id: username
label: Subscription manager username
- type: string
id: password
label: "Subscription manager password (🙈🙉🙊)"
secret: True
required:
- username
- password
This creates a credential with two keys: username and password. Note the secret: True flag on the password key - this means it's a secret that should be stored encrypted in the Ansible Tower database. We mark both keys as required, since you need them both.
Now how should we expose this to playbooks? The redhat_subscription module takes username and password as parameters, so the simplest way to do this is to pass them as extra variables. Hence, our injector looks like this:
extra_vars:
rhsm_password: '{{ password }}'
rhsm_username: '{{ username }}'
This passes the username and password for this credential via the extra variables rhsm_username and rhsm_password.
We can now create a credential that uses this type.
Now, we can write playbooks to use credentials of this type. Here's a short playbook example.
---
- hosts: all
gather_facts: True
tasks:
- name: Install RHSM and Insights
yum:
name: '{{ item }}'
state: present
with_items:
- redhat-access-insights
- subscription-manager
- name: Register system
redhat_subscription:
state: present
username: '{{ rhsm_username }}'
password: '{{ rhsm_password }}'
ANOTHER EXAMPLE - USING THIRD-PARTY CREDENTIAL STORAGE
A common usage pattern in large enterprises is the use of a third-party credential management system for managing passwords and keys for accessing hosts and services.
Before, this sort of environment was tricky to manage with Ansible and Ansible Tower. Now, with the combination of Ansible Tower Custom Credentials + Ansible Lookup Plugins, it becomes simple.
Here's an example using HashiCorp Vault. Other credential storage systems would follow a similar pattern.
First, we need a Hashi Vault credential type. There are two main parameters used to configure the connection to Hashi Vault - the URL to the vault itself, and a token to use. These are used by the lookup plugin via the environment variables VAULT_ADDR and VAULT_TOKEN.
That would make our credential input and injector definitions look like this:
fields:
- type: string
id: vault_server
label: URL to Vault Server
- type: string
id: vault_token
label: Vault Token
secret: true
required:
- vault_server
- vault_token
For Injector:
env:
VAULT_ADDR: '{{ vault_server }}'
VAULT_TOKEN: '{{ vault_token }}'
Given these, let's create our new credential.
To use this in our playbook, all we need is to mark that our hosts will actually get their connection information from vault.
We'll do that in inventory.
Here's a test playbook that demonstrates how we're connecting.
---
- hosts: all
gather_facts: true
tasks:
- name: "What's my name again?"
debug:
msg: '{{ ansible_user }}'
Now, let's run our playbook!
With this, we're using our single vault token to look up the appropriate password to connect to the managed hosts from our password vault, without ever knowing what the password might be. It could even be rotated every few weeks, and we'd never have to change our automation.
WRAP UP
We hope that this helps explains just how the new custom credential feature in Ansible Tower 3.2 can be used to allow you to automate more things in more ways.For more information on custom credentials, please see the Ansible Tower documentation
To get started with Ansible Tower, go to https://www.ansible.com/tower-trial
저자 소개
유사한 검색 결과
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리