Link to home
Start Free TrialLog in
Avatar of sunhux
sunhux

asked on

GPG keys configuration for RHEL7: what's best practice?

CIS RHEL7 doc recommends 1.2.3 GPG keys are configured according to site policy.

What's the best practice?

On my RHEL7, got the following, is it best-practice/compliant?
$ rpm -q gpg-pubkey --qf '%{name}-%{version}-%{release} --> %{summary}\n'
gpg-pubkey-fd431d51-4ae0493b --> gpg(Red Hat, Inc. (release key 2) <security@redhat.com>)
gpg-pubkey-2fa658e0-45700c69 --> gpg(Red Hat, Inc. (auxiliary key) <security@redhat.com>)
gpg-pubkey-7668xxxx-58axxxxx --> gpg(Docker Release (EE rpm) <docker@docker.com>)
ASKER CERTIFIED SOLUTION
Avatar of David Favor
David Favor
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Avatar of sunhux
sunhux

ASKER

We haven't got a Site Policy for this, so what would be a good Site Policy
for this looks like?
First best policy, don't use RHEL 7, as the Kernel is many years old.

Start with Ubuntu Bionic or RHEL 8, as a starting point for best speed + security.

After this, you'll develop a Site Policy for various security considerations.

Base on the above question, I'm unsure what Site Policy might mean... because... the above seems related to normal RedHat repositories, so if you'd like to use RedHat repositories, you must use these as described by RedHat. If you deviate, you won't be able to access these repositories or you'll have to forcibly break all security to access these repositories.

So... your question, as asked, is a bit confusing.

Maybe say why you care about modifying access to RedHat Repositories or state what exact problem you're trying to resolve.

Likely this is better asked in another question, as the answer to your original question...

What's the best practice?

Best practice for accessing RedHat or any other repositories seamlessly, is to follow RedHat/Other repository access steps, with no deviation.