Module Design Pattern

[Alexander Dacre]

I'm looking to build my first module with custom types and providers, but I have some questions that I've been unable to find answers to.

Lets say I have an application with a REST API that allows the creation of widgets. My custom type and provider would define what the widget looks like and contain code on how to create/delete etc. The problem is that the REST API is authenticated with basic auth over HTTPS. Now, my question: what is the general best practice for taking these credentials? Class parameters? On a type instance basis?

Thanks,

A

[jcbollinger]

On Friday, May 6, 2016 at 5:19:50 AM UTC-5, Alexander Dacre wrote:

I'm looking to build my first module with custom types and providers, but I have some questions that I've been unable to find answers to.

Lets say I have an application with a REST API that allows the creation of widgets. My custom type and provider would define what the widget looks like and contain code on how to create/delete etc. The problem is that the REST API is authenticated with basic auth over HTTPS. Now, my question: what is the general best practice for taking these credentials? Class parameters? On a type instance basis?

The provider for each type has to have everything necessary to manage instances of that type.  In this case, that includes authentication credentials.  I see these options for communicating the credentials to providers:

• hardcode them into the provider source (not recommended)
• store them in some other, external client-side resource, such as a file that the provider would read during catalog application (highly questionable)
• have the catalog builder feed them to the provider on a per-catalog basis.  This would require making them parameters (not properties) of the type.

If you go with the external resource, that probably means a file, and you can use any of the usual means to deliver an appropriate file to the appropriate place.

If you go with type parameters -- which seems the most likely approach to me -- then you still have to deliver the correct credentials in each declaration of an instance of your type, so there is a secondary question of how to feed those to the declaring class.  This is to a large extent the same analysis all over again, though whatever data store is involved is necessarily co-located with the catalog builder, so on the master in a master / agent setup.  My first inclination would be to use class parameters, or else maybe direct Hiera lookups, but analogs of all the same options there were for the type are also available for the class.


John

[Gareth Rushgrove]

I have a few examples of this.

I think my first recommendation would be to reuse a existing method of
providing the authentication details if one exists for the API in
question. So for instance:

https://github.com/garethr/garethr-kubernetes
https://github.com/puppetlabs/puppetlabs-aws

The Kubernetes module includes code to parse a standard
kubernetes.conf file. The AWS module loads config from environment
variables or from a config file (or just uses IAM so no config
internal required), as is standard for all the official AWS tools.

The Azure module does similar, but implements the logic itself which
might be of use.

https://github.com/puppetlabs/puppetlabs-azure/blob/master/lib/puppet_x/puppetlabs/azure/config.rb

Personally I don't think of authentication details as a property of
the type, more a property of the host. By decoupling the two you open
up options for dealing with those secrets how ever the end consumer
wants, ie. use keywhiz or vault or conjur, file permissions, manage
with Puppet resource, auditd rules, etc. All without requiring direct
Puppet integration.

Gareth

> Thanks,
> A
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/9b21c33e-e442-4890-91f3-b15baf47acec%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Gareth Rushgrove
@garethr

devopsweekly.com
morethanseven.net
garethrushgrove.com