Best Practice for Role Based Access to Repos/Content - Content Views or Activation Keys?

Support
1

I have a relatively simple Foreman infrastructure. For the purposes of this question:

  • One product per OS and major version (for the purposes of this question a single Alma8 Product is applicable. The Alma 8 Product initially contains the essential Alma 8 repos and EPEL. I subsequently added the official NGINX repo as we need access to newer versions than are carried in the Alma repos for security fix purposes.
  • Two lifecycles – pre-prod and prod.
  • One content view with access to all repos.

The best practice advice I have been given specified that I should try to keep things as simple as possible at a Product and Content View Level, and primarily use Activation Keys to fine tune access to content based on server roles.

I’ve create a pair of basic, initial Activation Keys – lets call them “ak_prod” and “ak_preprod”, which I’ve assigned to a test pre-prod and prod host, and been able to successfully promote content through the lifecycles. So far, so good.

Next I want to create a small test group of nginx webservers, I want these to also have access to the NGINX repo. I have therefore created a this “ak_preprod_nginx” activation key, which also has access to the NGINX repo enabled. However, on the sticking with my basic “ak_preprod” host, I have:

  • Disabled access to the NGINX repo on the two initial default keys.
  • Created a new content view.
  • Promoted it to pre-prod.
  • Performed a subscription-manager refresh/dnf clean all/unregister and register the pre-prod host.

However the NGINX repo is still showing up on a dnf repolist on the pre-prod box, so it seems to be ignoring my exclusion of the repo.

–

Additionally, and hopefully still on a related note, as a requirement I also need to add content filters, some universal, some more specific. For example, through my environments to avoid conflicts I want to have a default exclude all on the EPEL repo, then include filters for a small number of required packages, mostly tools such as atop.

So my question is, am I going about this the right way? I’m starting to lean towards thinking the advice I’ve been given about sticking to configuring hosts/roles at a Activation Key level being incorrect, and I should instead be creating a content view for every server role (or at least, every server role that requires its own specific repo config)? Possibly the fact I want to use filters would push me in that direction regardless, although I think it would result in some duplication of effort to set up the default filters.

Otherwise, does anybody know why my client host seems to be ignoring the repo exclusions in the activation key?

Many thanks.

Foreman/Katello versions 3.6/4.8

2

As an addendum, I’m coming at configuring repo restriction essentially from a “principle of least privilege” kind of angle, but it may be that I’m overthinking things and blocking access to extra repos by default is unnecessary and I can still get by with one Content View.

For example, if NGINX was to be installed on any other hosts, I can’t imagine I’d want any other scenario than blocking the Appstream version and installing the NGINX repo version instead. Reduced availability of additional installable packages is still probably generally sensible from a security angle however.

We’re quite a small organisation so unauthorised package install by other sysadmins isn’t a huge concern and anything major would need to run through myself essentially as I’m admin for the Foreman box. So ensuring uniformity and simplicity across the estate is potentially a higher priority.

3

So, one thing about activation keys - they only apply at the time of registration. Modifications to the keys AFTER a client is registered will not reflect onto an already registered client, only new ones (or reregistering the existing one).

Also remember that you can only have one content view per host (this is why the composite content views exist - to essentially stitch multiple content views into a single view). What you’re going to do is leverage composite views, content views, activation keys, and repository sets together to get what you want.

I do something like this for my environment (YMMV) where I have a content view that defines the Base Operating System and includes the OS repositories, subscription-manager repositories, and the katello client repository. I also have multiple additional content views for things like PostgreSQL, Microsoft RPMs, EPEL, etc. Now because I can only have one content view per host, all of the individual content views are consolidated into a single composite content view designated for my OS (i.e. I have a CCV for Oracle Linux 7, a CCV for Oracle Linux 8, a CCV for CentOS 7, etc.). I then configure my activation key for my particular OS (I have one for OL7, one for OL8, etc.) and within the activation key configure the repository sets to only enable the repositories I am interested in and disable the rest. You can specify multiple activation keys during the registration process that have additional repository sets configured to be enabled during the registration (i.e. one for your NGINX repo) but remember, there can only be ONE content view so make sure only one activation key has a content view defined.

It seems complicated, but if designed correctly it’s actually quite simple.

1 Like
4

Possibly the fact I want to use filters would push me in that direction regardless, although I think it would result in some duplication of effort to set up the default filters.

Yeah, if you want to have different package filters on different hosts, I think you’re going to need different CVs. There’s duplication if you’re applying some-same-some-different filters to the same repository, but if the filters for a particular repository or set of repositories are all shared and you do CCVs like mclausen is saying, you can share the filtered CV among your CCVs.

I’ve never used the “Override to Disabled” option for Activation Keys, but have no idea why it wouldn’t work. If it did, I would suspect that subscription-manager repo-override on the client might let you undo the initial Activation Key disablement, and since the repo’s still in the CV, that it would then be available (and the reverse: instead of trying to manage it at the Katello level, you could try disabling the repo client-side). But maybe you’ll find differently! You used to be able to exclude repos at the Product level using Subscriptions, but Simple Content Access got rid of that, I believe. Like you’re saying, depends on how excluded “excluded” needs to be.

5

This is correct. subscription-manager repo-override will let you control content overrides from the client after registration (use the --help option for usage) and is the same as what you can do in the web UI on the host details page → Repository Sets tab.

also, thanks @mclausen for your excellent explanation of the basic Katello use case!

6

Thanks for the relies guys, appreciated, sorry about the delay in following up.

I’ve now gone down the route of switching over to controlling repo combinations at a CV level rather than an AK level. I did the GL650 Foreman course at the end of last year and was advised against the use of Composite Content Views (I don’t recall if a precise reason was given at the time but presumably it related to avoiding complexity - that seems to be the main generic one - unless there were bugs relating to their use at some point in the past or something), but I think it still makes sense to use this at least for my “Base OS” Content View, otherwise I’d be setting up the same filters etc time and time again, so I’m going to implement that as well.