Bug 1983185

In a way this should be already doable. Each capsule has its own key pair. If each capsule is assigned to exactly one organization, then you already have different keys for different organizations. Or am I missing something?

> Wouldn't be better from a security PoV to have a ssh keypair per each OU and distribute the keys only to the capsules that need it?

Currently the key pair gets generated on the capsule and the private key never leaves the machine and no other machine knows it. If we went with this suggestion, the private key would have to live on Satellite's side and be sent over to the capsules which require it, which doesn't exactly feel like a security win.

On a side note, satellite allows integrating with various IDMs which could possibly help here. Wouldn't that be an option?

(In reply to Adam Ruzicka from comment #2)
> If each capsule is assigned to exactly one organization, then you already
> have different keys for different organizations. Or am I missing something?

This would be doable, at the same time highly overkill, especially if users
map a tenant in an openstack infra to a Sat6 OU, and tenants are a cheap, basic,
concept in the infra, so they spread.

> Currently the key pair gets generated on the capsule and the private key
> never leaves the machine and no other machine knows it. If we went with this
> suggestion, the private key would have to live on Satellite's side and be
> sent over to the capsules which require it, which doesn't exactly feel like
> a security win.

You are right, at the same time we may generate a new one on each capsule associated
with a OU or when that capsule is added to that OU, so no trasfer of keys and we have no
secretes shared among OUs

> On a side note, satellite allows integrating with various IDMs which could
> possibly help here. Wouldn't that be an option?

The concern reported is the existence of something shared between different entities,
that are expected to be totally independent, also from a Sat6 PoV.

thanks

Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team.  Thank you.

Based upon feedback during auto-closure, leaving this bugzilla open a while longer for additional investigation; however, it may be closed in a future iteration.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.