search

ansible-collections / community.hashi_vault

Ansible collection for managing and working with HashiCorp Vault.
https://docs.ansible.com/ansible/devel/collections/community/hashi_vault/index.html
GNU General Public License v3.0
81 stars 61 forks source link

Certify collection for use with Red Hat #131

Closed davidcba1 closed 3 years ago

davidcba1 commented 3 years ago
SUMMARY

Our organisation does not have access to galaxy.ansible.com so we are unable to use this collection easily but we do have access to the certified content in cloud.redhat.com. I'd like to propose that this collection is certified by following the process here

https://access.redhat.com/articles/4916901 "How do I get a Collection certified?"

ISSUE TYPE
COMPONENT NAME

N/A

ADDITIONAL INFORMATION

Would provide a level of trust to enterprise organisation and allow secure organisation to use a supported collection.

briantist commented 3 years ago

Hi @davidcba1 , I read over that doc and chatted with some community members about this, and I don't think certification is going to be possible at this time. I'm a community maintainer and while I aim to respond quickly to all things related to the collection, I'm not in a position to sign the necessary contracts with RedHat for certification.

I'll point out that Galaxy is not the only way to get/install the collection (although other methods, like installing directly from git are likely to be less appealing from a trust standpoint).

If there's any other steps you can think of that would potentially make the collection usable for you, please let me know, I'm happy to consider them. There's a lot of good stuff on the way and it'd be a shame not to be able to use it.

Thank you for reaching out!

davidcba1 commented 3 years ago

Hi @briantist,

Thanks for the quick reply - yea, it seems my only option to use this collection would be to git clone - checkout a version/tag, then ansible-galaxy build . - that'll get me the .tar.gz - then use that to install.

But as you're aware - there's a level of trust that is required.

Just for my clarification - is this collection not something that is officially supported by Hashi-vault?

briantist commented 3 years ago

Just for my clarification - is this collection not something that is officially supported by Hashi-vault?

@davidcba1 it is correct that this collection is not supported by or affiliated with HashiCorp (the makers of Vault).

But as you're aware - there's a level of trust that is required.

I'm not sure there's much I can offer in the way of trust other than that the source is here and publicly auditable, and that I'm happy to answer any questions about it. This collection is also part of the Ansible package, which has specific inclusion requirements that must be met so there is some level of standards that must be maintained for the collection to stay a part of the package.

You're also welcome to join the public #ansible-community channel on IRC or Matrix if you'd like to get a sense from other folks.

I'll add that the RedHat certification process seems to be primarily aimed at providing a level of customer support, and as far as I can tell doesn't entail code auditing or things of that nature (I could be wrong, but haven't seen any evidence of that). It appears to mainly offer a private/pre-trusted channel for delivery of the content, and an agreement between RedHat and the RedHat Partner that support issues can be raised with RedHat and be addressed by the Partner within some agreed upon measure. At least that's what I can gather without actually going through the process.

yea, it seems my only option to use this collection would be to git clone - checkout a version/tag, then ansible-galaxy build . - that'll get me the .tar.gz - then use that to install.

The ansible-galaxy command supports installing collections directly from a git repository so you can skip the separate build step unless you wanted to host the build artifact locally, like on an internal Galaxy NG server or something like that.

Our releases are all tagged (pushing the tag triggers the collection build and publish to Galaxy, which happens on a separate automation platform I don't have access to), so you can indeed target specific releases by tag.

davidcba1 commented 3 years ago

Hi @briantist - thanks for the updates and replies. I have mentioned this to Red Hat directly as well for their awareness. They are familiar with the space I work in and what restrictions I'm required to work within. Its also worth noting that community.general isn't avail either but that's a separate conversation I'm having with Red Hat.

I'll add that the RedHat certification process seems to be primarily aimed at providing a level of customer support, and as far as I can tell doesn't entail code auditing or things of that nature (I could be wrong, but haven't seen any evidence of that). It appears to mainly offer a private/pre-trusted channel for delivery of the content, and an agreement between RedHat and the RedHat Partner that support issues can be raised with RedHat and be addressed by the Partner within some agreed upon measure. At least that's what I can gather without actually going through the process.

Yea, having someone responsible to follow up and fix things is one thing, but it also means we point our ansible-galaxy at cloud.redhat.com instead of galaxy.ansible.com - and cloud.redhat.com requires auth, and is trusted by the company. https://docs.ansible.com/ansible/latest/galaxy/user_guide.html#configuring-the-ansible-galaxy-client mainly..

[galaxy_server.automation_hub]
url=https://cloud.redhat.com/api/automation-hub/
auth_url=https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token
token=my_ah_token

Yes, ansible-galaxy supports installing collections directly from git.. but only post 2.9 (Ansible Automation Platform (AAP) 1.2 ships with 2.9.. so can only install via .tar.gz or galaxy supported endpoint) .. which in this case is I'm required to setup and use Automation Hub - but that's what happens in an enterprise world!

Our releases are all tagged (pushing the tag triggers the collection build and publish to Galaxy, which happens on a separate automation platform I don't have access to), so you can indeed target specific releases by tag.

Cool & thanks that's good to know about your release process.

briantist commented 3 years ago

Got it, that all sounds good @davidcba1 !

Re: Ansible 2.9, I feel you. My company is also largely stuck on 2.9, but for different reasons that I'm working to resolve.

Part of that transition process involves us moving internal content to collections in separate repositories, and being able to to install those without having to run our own Galaxy server, so that does leave me in something of a conundrum.

I don't know whether it will be useful for you, but what I've done is created a little script that installs ansible-core 2.11 inside a python virtual environment, and uses the ansible-galaxy command from there. It's something like this:

$VIRTUALENV=<known path to virtualenv for this purpose>
python3 -m venv $VIRTUALENV
$VIRTUALENV/bin/pip install --upgrade pip
$VIRTUALENV/bin/pip install 'ansible-core>=2.11,<2.12'

$VIRTUALENV/bin/ansible-galaxy ${@}

Which can then be invoked the same way, so if this were called ans-gal.sh:

$ ./ans-gal.sh collection install git+https://gitserver/ns/collection.name.git

(you get the idea)

I gather, this is likely not useful for use with automation hub, but maybe it'll give you some ideas anyway.

davidcba1 commented 3 years ago

Thanks @briantist appreciate the tips.

Part of that transition process involves us moving internal content to collections in separate repositories, and being able to to install those without having to run our own Galaxy server, so that does leave me in something of a conundrum.

Well, with ansible 2.10+ you can call collections/requirements.yml (or roles/requirements.yml) and point directly at git repo/tag and for the upstream stuff if you have the connectivity just get it from upstream (galaxy.ansible.com). I can't do this.. so will eventually be setting up Automation Hub to mirror content internally - once approved (insert 1-2 years here... hehe)

We use Ansible tower, and have automated the same using ansible - but.. a venv running 2.11 is completely unsupported with Red Hat, also.. Ansible Tower will use ansible 2.9.x to download projects and inventories, meaning collections don't work with collections/requirements.yml as it'll use 2.9 to "stage" things, but 2.11 to run the playbook with (arg!)

I have workaround and solutions to pretty much everything encountered.. but want to simplicity and align things as much as possible - really looking forward to AAP 2.0 .. container driven ansible - so no more venvs!