[DRAFT] ARO-15052: support cluster credential retrieval for aro_hcp/v1alpha1

[JameelB]

h4. What

The design document for this API can be found in XCMSTRAT-1135.

The proposed endpoints in ARO HCP v1alpha1 is as follows:

GET POST DELETE
/clusters/{cluster_id}/break_glass_credentials

GET 
/clusters/{cluster_id}/break_glass_credentials/{break_glass_credential_id}

The break glass credentials API for both clusters_mgmt/v1 and aro_hcp/v1alpha1 should have similar features apart from the following differences:

• Creating and deleting break glass credentials for ARO HCP clusters needs to be done asynchronously. The POST and DELETE endpoints must return a 202 Accepted status code.
• Additional states were added: issuing, revoking and denied

A few additional properties has been added to clusters_mgmt/v1 BreakGlassCredentials type:

• CreationTimestamp: added in order to determine when to clean up 'denied' and 'failed' credentials. It may also be useful for auditing/tracing.

  For existing credentials, these will be set to a default of zero time. These will be omitted in the API output. Moving forward, all break glass credentials under both clusters_mgmt/v1 and aro_hcp/v1alpha1 will have this property set.

• StatusDetails: added to contain additional properties about the break glass credential's state such as 'message'. As there is already an existing Status property, we can't align its name with the rest of the other endpoints like Node Pools to capture this information. A few alternative options on naming were considered such as 'State' or 'StatusContext'.

Additional endpoints that we may consider adding:

GET
/clusters/{cluster_id}/break_glass_credentials/{break_glass_credential_id}/status

• A similar proposal was made for external authentication provider, based on the discussion there, we may want to consider adding this endpoint for break glass credentials as well: XCMSTRAT-574: add support for external_auth to the aro hcp v1alpha1 api #1047 (comment)

Only the openapi files have been generated for now to make it easier to review the changes here.

Resulting changes in the ARO HCP API

[openshift-ci-robot]

@JameelB: This pull request references ARO-15052 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.20.0" version, but no target version was set.

Details

In response to this:

h4. What

The design document for this API can be found in XCMSTRAT-1135.

The proposed endpoints in ARO HCP v1alpha1 is as follows:

GET POST DELETE
/clusters/{cluster_id}/break_glass_credentials

GET 
/clusters/{cluster_id}/break_glass_credentials/{break_glass_credential_id}

The break glass credentials API for both clusters_mgmt/v1 and aro_hcp/v1alpha1 should have similar features apart from the following differences:

• Creating and deleting break glass credentials for ARO HCP clusters needs to be done asynchronously. The POST and DELETE endpoints must return a 202 Accepted status code.

A few additional properties has been added to clusters_mgmt/v1 BreakGlassCredentials type:

• CreationTimestamp: added in order to determine when to clean up 'denied' and 'failed' credentials. It may also be useful for auditing/tracing.

For existing credentials, these will be set to a default of zero time. These will be omitted in the API output. Moving forward, all break glass credentials under both clusters_mgmt/v1 and aro_hcp/v1alpha1 will have this property set.

• StatusDetails: added to contain additional properties about the break glass credential's state such as 'message'. As there is already an existing Status property, we can't align its name with the rest of the other endpoints like Node Pools to capture this information. A few alternative options on naming were considered such as 'State' or 'StatusContext'.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[openshift-ci]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: JameelB
Once this PR has been reviewed and has the lgtm label, please assign vkareh for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[openshift-ci]

Hi @JameelB. Thanks for your PR.

I'm waiting for a openshift-online member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[openshift-ci-robot]

@JameelB: This pull request references ARO-15052 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.20.0" version, but no target version was set.

Details

In response to this:

h4. What

The design document for this API can be found in XCMSTRAT-1135.

The proposed endpoints in ARO HCP v1alpha1 is as follows:

GET POST DELETE
/clusters/{cluster_id}/break_glass_credentials

GET 
/clusters/{cluster_id}/break_glass_credentials/{break_glass_credential_id}

The break glass credentials API for both clusters_mgmt/v1 and aro_hcp/v1alpha1 should have similar features apart from the following differences:

• Creating and deleting break glass credentials for ARO HCP clusters needs to be done asynchronously. The POST and DELETE endpoints must return a 202 Accepted status code.

A few additional properties has been added to clusters_mgmt/v1 BreakGlassCredentials type:

• CreationTimestamp: added in order to determine when to clean up 'denied' and 'failed' credentials. It may also be useful for auditing/tracing.

For existing credentials, these will be set to a default of zero time. These will be omitted in the API output. Moving forward, all break glass credentials under both clusters_mgmt/v1 and aro_hcp/v1alpha1 will have this property set.

• StatusDetails: added to contain additional properties about the break glass credential's state such as 'message'. As there is already an existing Status property, we can't align its name with the rest of the other endpoints like Node Pools to capture this information. A few alternative options on naming were considered such as 'State' or 'StatusContext'.

Only the openapi files have been generated for now to make it easier to review the changes here.

Resulting changes in the ARO HCP API

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[machi1990]

/ok-to-test

[openshift-ci-robot]

@JameelB: This pull request references ARO-15052 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.20.0" version, but no target version was set.

Details

In response to this:

h4. What

The design document for this API can be found in XCMSTRAT-1135.

The proposed endpoints in ARO HCP v1alpha1 is as follows:

GET POST DELETE
/clusters/{cluster_id}/break_glass_credentials

GET 
/clusters/{cluster_id}/break_glass_credentials/{break_glass_credential_id}

The break glass credentials API for both clusters_mgmt/v1 and aro_hcp/v1alpha1 should have similar features apart from the following differences:

• Creating and deleting break glass credentials for ARO HCP clusters needs to be done asynchronously. The POST and DELETE endpoints must return a 202 Accepted status code.
• Additional states were added: issuing, revoking and denied

A few additional properties has been added to clusters_mgmt/v1 BreakGlassCredentials type:

• CreationTimestamp: added in order to determine when to clean up 'denied' and 'failed' credentials. It may also be useful for auditing/tracing.

For existing credentials, these will be set to a default of zero time. These will be omitted in the API output. Moving forward, all break glass credentials under both clusters_mgmt/v1 and aro_hcp/v1alpha1 will have this property set.

• StatusDetails: added to contain additional properties about the break glass credential's state such as 'message'. As there is already an existing Status property, we can't align its name with the rest of the other endpoints like Node Pools to capture this information. A few alternative options on naming were considered such as 'State' or 'StatusContext'.

Only the openapi files have been generated for now to make it easier to review the changes here.

Resulting changes in the ARO HCP API

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[machi1990]

Is the method async? If so, should we be returning 202 instead

[JameelB]

yes its async, but I'm waiting on #1049 to get merged so i can generate the async add method. That PR updates the metamodel that includes support for that.

You'll notice below that Delete is the same. I'm going to regenerate this once that pr is merged.

[JameelB]

The initial proposal for this property was as follows:

"status_details": {
    "message": "cert failed to be issued for x reason"
}

However, after reviewing the node pool state, I'm proposing to align this with the NodePoolStatus and NodePoolState types to have consistency as to how the status/state is defined across the API.

Instead, the new property will be as follows:

"status_details": {
    "kind": "string",
    "id": "string",
    "href": "string",
    "message": "string",
    "state": {
         "last_updated_timestamp": "2025-06-13T12:43:34.624Z",
         "value": "issuing"
    }
},

[vkareh]

I agree with making this a class, but should it be named status instead of status_details? I haven't seen the use of a status_details struct before, so this seems to add additional disparities between resources.

[miguelsorianod]

I agree with making this a class, but should it be named status instead of status_details? I haven't seen the use of a status_details struct before, so this seems to add additional disparities between resources.

You are correct pointing out this @vkareh, I guess here the issue is that there is a "status" attribute in the top-level of the break glass api resource already, with its type being an enum (a typed string in Go). See model/clusters_mgmt/break_glass_credential_type.model file in the main branch of this repo

[JameelB]

+1 it would be nicer to have it as status but as Miguel mentioned it would be difficult to change as we will be switching it from a string to a struct in an existing api used by rosa hcp. The status_details was proposed as an alternative.

The other option was using state as a struct but this isn't consistent with how we use this field in other resources, where it is either a string that indicates the status of the resource, or a struct that contains the value of the state along with other state metadata like last_updated_timestamp.

Accepting any alternatives here 🙏

[JameelB]

Set this to type BreakGlassCredentialStatus to align with the outer Status since it's an enum. Alternatively, we could set this to a string type which would make it a little bit more flexible to add new states later on.

[vkareh]

Would BreakGlassCredentialStatusValue or BreakGlassCredentialStateValue be better alternatives? That way we can use BreakGlassCredentialStatus for the credentials.status struct.

[JameelB]

Sounds good, will update this to BreakGlassCredentialStatusValue

[openshift-ci-robot]

@JameelB: This pull request references ARO-15052 which is a valid jira issue.

Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the epic to target the "4.20.0" version, but no target version was set.

Details

In response to this:

h4. What

The design document for this API can be found in XCMSTRAT-1135.

The proposed endpoints in ARO HCP v1alpha1 is as follows:

GET POST DELETE
/clusters/{cluster_id}/break_glass_credentials

GET 
/clusters/{cluster_id}/break_glass_credentials/{break_glass_credential_id}

The break glass credentials API for both clusters_mgmt/v1 and aro_hcp/v1alpha1 should have similar features apart from the following differences:

• Creating and deleting break glass credentials for ARO HCP clusters needs to be done asynchronously. The POST and DELETE endpoints must return a 202 Accepted status code.
• Additional states were added: issuing, revoking and denied

A few additional properties has been added to clusters_mgmt/v1 BreakGlassCredentials type:

• CreationTimestamp: added in order to determine when to clean up 'denied' and 'failed' credentials. It may also be useful for auditing/tracing.

For existing credentials, these will be set to a default of zero time. These will be omitted in the API output. Moving forward, all break glass credentials under both clusters_mgmt/v1 and aro_hcp/v1alpha1 will have this property set.

• StatusDetails: added to contain additional properties about the break glass credential's state such as 'message'. As there is already an existing Status property, we can't align its name with the rest of the other endpoints like Node Pools to capture this information. A few alternative options on naming were considered such as 'State' or 'StatusContext'.

Additional endpoints that we may consider adding:

GET
/clusters/{cluster_id}/break_glass_credentials/{break_glass_credential_id}/status

• A similar proposal was made for external authentication provider, based on the discussion there, we may want to consider adding this endpoint for break glass credentials as well: XCMSTRAT-574: add support for external_auth to the aro hcp v1alpha1 api #1047 (comment)

Only the openapi files have been generated for now to make it easier to review the changes here.

Resulting changes in the ARO HCP API

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository.

[JameelB]

@miguelsorianod @vkareh @tzvatot @lucasponce @andreadecorte PTAL 🙏

[vkareh]

Not sure if it has been brought up, but the "break-glass" moniker no longer holds, since these are not "break glass" in the sense that they're only used as an emergency when trying to access/debug a cluster. Any chance we can rename the ARO API to be Credential or AdminCredential?

[JameelB]

We can, as long as we're in agreement of the name change. It wasn't a requirement before, but happy to change it. I don't think it should break anything as these are new endpoints 🤔

[vkareh]

I agree with making this a class, but should it be named status instead of status_details? I haven't seen the use of a status_details struct before, so this seems to add additional disparities between resources.

[vkareh]

Would BreakGlassCredentialStatusValue or BreakGlassCredentialStateValue be better alternatives? That way we can use BreakGlassCredentialStatus for the credentials.status struct.

[openshift-merge-robot]

PR needs rebase.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.