| Summary: | [RFE] subscription-manager should be able to handle consumerid and activationkey options simultaneously | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Eric Sammons <esammons> |
| Component: | subscription-manager | Assignee: | Devan Goodwin <dgoodwin> |
| Status: | CLOSED NOTABUG | QA Contact: | Entitlement Bugs <entitlement-bugs> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 6.2 | CC: | bkearney, dgoodwin, khong, suli, yuzheng |
| Target Milestone: | rc | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2012-02-28 16:55:00 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Bug Depends On: | |||
| Bug Blocks: | 738066 | ||
We need to try for the simplest solution possible here first as this request is a little way outside of anything that was designed or planned for in candlepin. --consumerid is not actually a new registration event, the consumer already exists, we're just assuming it's identity. --activationkeys are only relevant/used during creation of a new consumer, there's nowhere else in the API you can apply one. So today, combining these two things doesn't exactly jive. Our first thought for the example you give, could the IT Asset manager using SAM specify the activation keys to apply to the consumer when he's pre-creating it in the webUI. The sys admin then just "registers" with --consumerid, and that consumer already has the subscriptions applied to it from the activation key? If not, then we can discuss some other alternatives that are a bit more costly. (and these might be required anyhow if not using a username/password is a priority) Some more thoughts, there are essentially two features requested here, 1. allow register with both --consumerid and --activationkeys (which also implies --org) 2. do not require username/password in this scenario There are some significant issues with solving both that boil down to authentication. When registering with --consumerid you are assuming the identity of an existing consumer. Rather than a POST /consumers that would be done during a normal registration (creating a new consumer), this operation boils down to just doing a GET /consumers/uuid, basically just to fetch the consumer's identity certificates. Bear in mind this could be used to assume the identity of any consumer in any org, meaning there are some substantial security implications. As such GET /consumers/uuid is protected and will not allow anyone to view it unless their credentials grant them access to the consumer being requested. This is why we require username + password to do a register --consumerid. So if we were to eliminate the need for the username/password, we would have to either remove all security on GET /consumers/uuid (which is way too risky), or implement some means by which defining activation keys and an org gets you some kind of credential that allows you to perform the GET. This is essentially an entirely new method of authenticating against the candlepin API. As for (1), assuming we are ok with continuing to require username + password when using --consumerid, we could probably solve by implementing a new API call that let you apply an activation key to an existing consumer. However the proposal in comment #1 should work with the code as it exists today. As this is no longer supported in SAM we are closing this issue as not a bug. There is some confusion on what Satellite could previously do and if it involved assuming the identity of a pre-existing consumer, or if it was just plain use of activation keys to register normally and then grant entitlements as defined by the key. This will be dealt with in the future if the requirement arises. |
Description of problem: The current version of subscription-manager does not support the use of consumerid and activationkey on the same command line. In specific corporate environments it may be required to define a system (consumerid) and expect that the system to register against a specific activationkey without giving the sysadmin a username / password into the backend (SAM or Katello). Use case: 1. Department is ordering new hardware to roll out a application. 2. IT Asset management for the company defines a Org in SAM and Red Hat portal - In portal/subscription management a new manifest with specific Qtys. of subscriptions are applied - Manifest is downloaded and installed into SAM's applicable org. 3. IT Asset management pre-defines systems to SAM. 4. IT Asset management creates a activation key. 5. IT Asset management applies specific subscriptions to activationkey 6. IT Asset management passes on to the department's SysAdmin the following command to be run in %post in ks.cfg or manually upon successful build. # subscription-manager register --consumerid [uuid] --activationkey [deptkey] This allows for a separation of duties, securing of the SAM (Katello) environment, reduction in number of commands to be run, and proactive asset management. Keep in mind that today passing consumerid on the command line will require a username/password whereas activationkey does not so by passing both we should eliminate the need for hard coding in clear text username / password combinations and avoid creating users unnecessarily in SAM / Katello.