WIP: Implement IAM Authentication

[jackcasey-visier]

These changes are a WIP 😄

Summary

This proposal is to add different Vault authentication mechanisms to this plugin, as an alternative to using the Token directly

There are a number built into Vault that would be feasible: https://www.vaultproject.io/docs/auth

Implementation

The authentication portion is completed in the special_auth.rb file. Currently, configuration for IAM is only specified, however this is setup in a way that adding new authentication methods should be plug-and-play

For example, adding GitHub authentication would look like: (pseudocode)

def authenticate(options, client, context)

  auth_types = {
    'aws_iam' => method(:aws_iam_auth),
    'github'     => method(:github_auth)
  }

  auth_types[options['type']].(options['config'], client, context)

end


def github_auth(config, client, context)

    # Logic for Github authentication 
    client.auth.github()

end

The client returned from these functions would be authenticated and ready to use

Configuration Changes

To implement this, the configuration would need to be altered. The token section can be omitted, with a new authentication section added:

For example, a current config may look like:

---

version: 5

hierarchy:
  - name: "Hiera-vault lookup"
    lookup_key: hiera_vault
    options:
      confine_to_keys:
        - '^vault_.*'
        - '^.*_password$'
        - '^password.*'
      ssl_verify: false
      address: https://vault.foobar.com:8200
      token: <insert-your-vault-token-here>
      default_field: value
      mounts:
        some_secret:
          - %{::trusted.certname}
          - common
        another_secret:
          - %{::trusted.certname}
          - common

Here is a similar config, using IAM authentication:

---

version: 5

hierarchy:
  - name: "Hiera-vault lookup"
    lookup_key: hiera_vault
    options:
      confine_to_keys:
        - '^vault_.*'
        - '^.*_password$'
        - '^password.*'
      ssl_verify: false
      address: https://vault.foobar.com:8200
      authentication:
        type: aws_iam
        config:
          role: vault-client-role
      default_field: value
      mounts:
        some_secret:
          - %{::trusted.certname}
          - common
        another_secret:
          - %{::trusted.certname}
          - common

The main difference is this snippet here:

authentication:
  type: iam
  config:
    iam_role: vault-client-role

This would allow any different form of authentication to be supported, even though they may require different configurations

The hiarchy of authentication methods are as follows:

1. VAULT_TOKEN environment variable
2. token specified in the configuration
3. authentication specified in the configuration

Each type will need to be specified in the special_auth.rb function

Next Steps

I'm opening this PR in WIP status to get the conversation going 😄

The following would still need to be worked on:

• Tests
• Document updates

Are any maintainers able to provide some input into a possible testing strategy for this? I have Terraform code available to create a full end-to-end test in AWS, but not sure how well that'd fit into the current testing patterns 😅

Thanks!!

Related to #66

[jackcasey-visier]

@petems Just a friendly poke 😅 Hope all is well!

If possible, are you able to provide a bit of feedback on this? Thanks!

[petems]

Hello! Yes, sorry I've been pretty busy and still mulling over accepting this or not. The work is great and I dont want it to go to waste, but...I think I'd rather keep the module as simple as possible, and rely on people using a tool like vault-agent to do auth via different methods.

I think you might even be able to have this as a separate repo and treat it like a plugin, so those who dont want to use vault-agent and want specific direct auth methods like AWS could include both modules and then have a choice... how would you feel about that?

[petems]

Or, maybe even take the original idea and add in the auth plugin system, then have the various auths as ssperate modules?

[jackcasey-visier]

@petems Thank you for the feedback! I can appreciate you want to keep the module as simple as possible 😄

Are you able to get me pointed in the right direction if we wish to go the plugin route? Would I build a new package, then import into this one if those authentication methods are required?

Any insight would be greatly appreciated!