-
Feature Request
-
Resolution: Won't Do
-
Normal
-
None
-
None
-
None
-
Product / Portfolio Work
-
None
-
False
-
None
-
None
-
None
-
None
-
-
None
-
-
None
-
None
-
None
1. Proposed title of this feature request
Azure Pipelines integration with OCP.
2. What is the nature and description of the request?
The Customer would like to use the Azure Service Principals (Azure AD) to deploy applications into OCP. According to Bugzilla RHBZ#2024597, client-go credential plugins are not supported in OpenShift.
In the changelog https://mirror.openshift.com/pub/openshift-v4/clients/ocp/4.9.9/changelog.html indeed we can find exec credential provider struct added, due to the fact we don’t want to diverge from the upstream code.
The feature itself is not available. This means the `client.authentication.k8s.io` resource is not available in the API server. This leads to the point where kubelogin with ExecCredentials won't work in Openshift the same way as on vanilla Kubernetes.
3. Why does the customer need this? (List the business requirements here)
In order to natively integrate our CI/CD environment(Azure DevOps) into k8s environment(OCP on-prem but could help more natively integrate ARO into AZDO/AAD as well) we would like to use Azure Service Principals(Azure AD) as identities via Azure Pipelines to deploy our applications into OCP. This is to not have any handovers or exposure of secrets/token(SA Tokens being put into Service Connections) and/or have the “burden” of managing NPA’s (Processes to keep password in keyvaults) making the access between pipeline and platform “transparent/invisible” to the users of the pipeline.
4. How would the customer like to achieve this? (List the functional requirements here)
By using ExecCredentials (client.authentication.k8s.io/v1) being able to use Azure Service Principals(SPN) via kubelogin (https://github.com/Azure/kubelogin) as identities in OCP for deployment purposes from Azure DevOps.
As SPN’s are not “Users” in the case of OpenID implicit/authentication flow, they cannot be used with the OpenID Connect IDP connected to AzureAD,
This use case would be more to have the client credential grant flow implemented.
5. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.
Have a running OCP Cluster (with access to Azure AD) and use the SPN login flow as described here: https://github.com/Azure/kubelogin#service-principal-login-flow-non-interactive