-
Feature
-
Resolution: Unresolved
-
Normal
-
None
-
None
-
False
-
-
False
-
Red Hat Enterprise Linux
Feature Overview
Customers can launch their VMs and enroll/join them into an already existing Identity Management deployment. This Feature is part of a collection of Features to enable support for various Identity Provider solutions.
When I provision my host(s), it can configure them to join an established Active Directory domain, so that users can authenticate to and access (subject to the domain's access policies) the host after launch.
Background, and strategic fit
Enterprise customers with established Identity Management deployments will want any new hosts they launch to become a part of their established domains. ImageBuilder and HMS launch services should provide this capability in an automated fashion. In other words, no additional user actions are required to enroll the machine post-launch.
This meets several customer goals:
- Lower costs through increased automation
- Improve security through access and security policies being applied to the machines immediately after launch.
We see it as an opportunity to bring small enterprise customers (or internal departments) which have their own Active Directory domain, to provision hosts and take advantage of their own Identity Provider solution (mostly due to internal policies or compliance).
Glossary
- Blueprint: A registered identity provider domain, making it available for use with the Domain Join feature. The term is just a placeholder; the product might use a different name.
- Domain: a deployment of an identity provider solution, such as Identity Management in RHEL.
- Domain Join: enrolling a machine as a client of an identity management domain.
- Enrollment: see Domain Join
- Host: A VM, typically registered with the console.redhat.com Inventory and possibly created via the Launch workflow.
- Image: A VM image available for use in the Launch workflow. It was possibly created via Image Builder.
- Launch: The Launch workflow, which creates VMs in the customer's clouds.
- Provisioning: see Launch
Delivery phases
- Spikes: We need to break some big rocks and understand how we will make the connection between AD and Insights. In the previous Feature, we controlled the bits, but now it is a bit different. Those spikes will give us a roughly idea on how to overcome and create the solution.
Functional Requirements
| Requirement | Notes | Phase |
| Register Active Directory domain in ConsoleDot, without storing any secrets or credentials in ConsoleDot. | This will be a separate workflow. The result of registration is that the registered domain becomes available for Domain Join. | 1 |
| Being part of Launch workflow | Launched hosts shall (attempt to) join a registered Domain, assuming the image contains the required packages and configuration. | 1 |
| Being part of Image Builder workflow | Images can be general and intended for enrollment in arbitrary identity providers (or left unenrolled). The choice ultimately happens at Launch. Also, a Blueprint associated with an Image might have been deleted or disabled at Launch time.However it could still be useful to be able to annotate an image with particular Blueprints as a hint to the Launch workflow. | 2 |
| Heuristics for automatically selecting/suggesting a domain for image/provisioned machine. | To assist the user we can use data we know or can collect (e.g. via Insights) to suggest a Blueprint. | X |
| Identity Provider domain included in Launch "Blueprint"/"Template" | To be explored later on -> Automated way to grab domains from insights and provide that information to the end user ------------------------------------- If IDM servers are already enrolled into inventory and we are aware of those servers/domains we can grab the settings and create/suggest that domain during the Domain Registration workflow. We need to implement this capability in insights (to deliver the information about domains/servers into Insights), allowing us to proceed with the suggestion. https://issues.redhat.com/browse/HMSIDM-160 |
2 |
| Bulk Launch | Ability to launch more than one instance at a time using Domain Join feature | 2 |
| Removing machine from domain when it is removed/deleted | Discuss it further (See Non Functional Requirements) | X |
| Gracefully handle temporary IDM server unavailability. | IDM Server can be unavailable at launch/enroll time. We should ensure that the enrollment completes when the IDM server becomes available again. | X |
| Blueprint Validation during insertion (During "blueprint" (IdP) setup we can launch a VM, and attempt to join it, to verify the blueprint configuration.) Non-Functional Requirement related (Availability) | A way to validate if the blueprint/configuration added is correct and can be used - users can anticipate any kind of mistype or misconfiguration in advance, not only after launching the machine. This does not guard against all join failure scenarios, e.g. image does not have required packages, image has conflicting crypto configuration, connectivity issue between cloud(s) in which VM launches and the IdP). |
X |
| Create and manage Blueprint registrations, and selecting a Blueprint during Launch workflow | As for registrations, it is a privileged operation, and we will use ConsoleDot CIAM RBAC As for Launch, I am not sure what the requirements should be (Question) |
2 |
| Show machine join domain and status Inventory. | Example states: * No domain (customer does not want it joined to any domain)
|
X |
Non-Functional Requirements
Please take a look at this nice guide talking about NFRs Top 10 Architecture Characteristics / Non-Functional Requirements with Cheatsheet
| Category | Requirement |
| Scalability |
|
| Availability | Assumption:
|
| Extensibility | The service implementation should consider future integrations with other identity management solutions, such as AD, AzureAD, AWS IAM, etc. Portability: The implementation of components to be deployed on, or adjacent to, Identity Management in RHEL servers, should consider possible future integration with non-Red Hat-managed deployments of HMS services, or alternative infrastructure management solutions (e.g. Satellite). |
| Consistency | Assumption: Servers are properly configured on customer side |
| Resiliency | Disaster Recovery: Data stored by the CRC Domain Join service(s) must be backed up and recoverable. These data are the organisations' IdP registrations. This data is "slow-moving" (add/modify/remove are infrequent operations). Other data stored in CRC used by this feature are owned by other services (e.g. inventory, launch) and those services are responsible for ensuring the resiliency of their data. Scenario: Domain Join service dies in the middle of provision prep for a burst launch. What happens? We need to consider this. Scenario: During launch, Domain Join server (IDM in RHEL server) to be enrolled doesn’t respond. What happens? In other words: Launched host didn’t finish the enrollment/join to the server due XYZ. |
| Usability | API Contract: All documentation should be available for future integration and internal usage Accessibility/UI/UX: bdellasc aboscatt@redhat.com to work together in the idea to create a proposal Verbiage: bdellasc aboscatt@redhat.com we should get in touch to understand and create the verbiage to be used. Also we should get in touch with CIAM team to merge our solutions and define the proper wording. Notification: Administrators should be aware of events. Question: How to not spam a bunch of notification in the screen, but let the user aware of what is happening? bdellasc aboscatt@redhat.com to work on those |
| Observability | What events do we want to log? Where should we store them? Should we create any alerts? Send email notifications (can it be configurable?)? Logging: Error, Warning, Success, Debug Alerts & Monitoring:
|
| Security | No keys or credentials for customer's IdM should be stored in the console. No keys or registration codes should float through console infra in clear. No connections from control plane (console) to the data plain (system and IdM) should h appen - only the other way around. |
| Durability | In attempt to meet this as a long time, the clean-up of any kind of enrolled machine is not considered as part of this MvP (check Functional Requirement). |
| Agility | None |
Use Cases (User Experience & Workflow)
#1 As a provisioning administrator, I want to have the ability to create a provisioning blueprints that includes my Active Directory infrastructure information to configure the provisioning host during the configuration step with a pre-defined blueprint.
#2 As a provisioning administrator, I want to have the ability to specify my Active Directory infrastructure information during an ad hoc building process.
#3 As a provisioning administrator, I want the provisioning host(s) that I create to automatically join a domain after its creation using either the blueprints(#1) or ad hoc(#2).
- Specific to Launch/Provisioning, not including Image Builder yet (see MVP list)
#4 As a ConsoleDot administrator, I want to have the ability to turn this feature on and off during runtime, allowing a crisis management or incident management without the need to deploy a new code.
- Toggle feature for “Domain Join” in Launch/Provisioning workflow
- Toggle feature for “Blueprint” Settings
#5 As a ConsoleDot administrator, I want to have the ability to grant and revoke permissions to people over my organization to use the Domain Join Feature* in ConsoleDot.
- *Create and manage Blueprint registrations, and selecting a Blueprint during Launch workflow
- As for registrations, it is a privileged operation and we will use ConsoleDot CIAM RBAC
- As for Launch, I am not sure what the requirements should be (Question added)
Customer Considerations
Considerations:
- Versioning: Should be the same ImageBuilder and Provisioning are supporting
- Heads-up: Some versions of RHEL are losing support from Ansible
- We are using RH Workers (expand here more if needed).
- Do we want agents to be in another Linux versions (i.e. Ubuntu)?
- Andre:: To explore it with PO Board next Monday (Do we have the ability to launch Ubuntu Machines using the current workflow?) Is it registered withing RH Connector? Is it known to inventory?
- Automation: Takes user configuration and makes it easy as possible
- If IDM servers are already enrolled into inventory and we are aware of those servers/domains we can grab the settings and create/suggest that domain during the Domain Registration workflow.
- We need to implement this capability in insights (to deliver the information about domains/servers into Insights), allowing us to proceed with the suggestion.
- https://issues.redhat.com/browse/HMSIDM-160
- Things should appear in a workflow manner
Customer Information/Supportability
Data we need to collect:
- What is the average number of launched machines in a single operation (batch)?
- We would like to see the distribution of this data (i.e. single host, from 2 to 5, from 6 to 20, from 20 to 50, etc). No preferences regarding the scale, it is important to distinguish between a single machine and multiple machines, finding the most common number to base our settings and performance.
- Lifetime of the hosts
- It will dictate and affect the non-mvp "delete orphan servers from IDP" epic!
- What is the distribution of clouds being used?
- Based on this feature availability to customers, which ones are using it?
- We understand that not all customers have this kind of scenario, but based on those who can, we would like to understand if they are using or not
- Are customers aware of this feature? Do they explicitly understand the benefits and decided not to use it?
- What types of customers are using it? How large are they? Machinery? Size?
- How to reach out to those customers to get feedback regarding the feature?
- Is this solving the problem they have? What are they missing? What is preventing them from solving the problem we are proposing to solve with this feature?
- If customers can’t use it:
- What is preventing them from using it? Security? Compliance?
- Missing integration with AD? LDAP? IdP?
- Are they using local files?
Documentation Considerations
- -< New Content, Updates to existing content, Release Notes, or No Doc Impact
- How do we expect customers will use the feature? For what purpose(s)?
- What reference material might a customer want/need to complete [action]?
- Is there source material that can be used as reference for the Technical Writer in writing the content? If yes, please link if available.->
- FYI: anikandr@redhat.com I believe a point of contact for HMS Docs should be viyengar@redhat.com
Interoperability Considerations
Test scenarios will involve deploying Active Directory Domains to be registered as Blueprints. Hosts shall be Joined to the Domains.
Questions
| Question | Outcome |