Deployments without passwords with SAP Continuous ...

holger_partsch

This blog explains how to use BTP's capabilities to establish secure authentication between the SAP Continuous Integration and Delivery service and the Cloud Foundry runtime without sharing any kind of secret.

The blog comes in three sections:

Motivation: Why it is not a good idea to share secrets
Walkthrough: The steps to enable the scenario
Deep Dive: More technical details on security aspects

If you're only interested in the "doing" part, feel free to skip directly to the walkthrough section.

Motivation

Let's assume you have a development project that you want to build with the SAP Continuous Integration and Delivery service and then deploy to BTP Cloud Foundry.

For the deployment, some form of authentication is required between the SAP Continuous Integration and Delivery service and the runtime (Cloud Foundry). Often, this is done by sharing a secret piece of information with the SAP Continuous Integration and Delivery service. That can be a password, a service key, or a cryptographic private key.

But why is secret sharing actually a bad idea? Secret sharing is the little brother of the dreaded "secret sprawl". An organisation suffers from secret sprawl, if there are copies of secrets distributed over different places, leading to a loss of transparency and accountability. Secrets need to be changed, either in a planned way or (worst case) because of a security incident. To do so, one needs to know all the places where a secret is stored. Forget one, and an important technical user might be locked out.

You end up with an inventory of credentials and stored secrets, something which is—in my experience—hard to maintain.

How can we avoid this whole rigmarole? The best solution is to dispense with secret sharing altogether and to instead define a trust relation between two systems. Sometimes that is not possible, but if two services belong to the same platform, you should expect that it is.

Key Benefits

A solution based on configured trust without secret sharing thus provides:

No operational efforts for secret rotation.
Improved security: Instead of tracking use of secrets, there is only one trust configuration, which can be disabled if necessary.

Walkthrough

Enough chit-chat, let's do some work. Here is a step-by-step guide how SAP Continuous Integration and Delivery can gain access to Cloud Foundry in order to deploy an application.

Requirements

A Cloud Identity Services tenant which acts as a custom identity provider (IdP) for platform users.
A user within the Cloud Identity Services tenant who has the developer role on the target space (the space the application should be deployed to).
A subaccount with a subscription to the SAP Continuous Integration and Delivery service. You need the "CICD Service Administrator" role to configure jobs and credentials.
A project you want to build, test, and deploy.

Certificate-based Authentication Credentials

Let's start in the SAP Continuous Integration and Delivery service. Authentication in this service is modeled via credentials. We need a credential of type "Certificate-Based Authentication for Custom IdP":

The following data is required:

The email of the technical user.
The hostname of the SAP Cloud Identity Services tenant.
The origin key used when configuring the tenant as custom IdP for platform users.

That's it. No secrets here!

Once you hit "Create" the detailed view appears:

There is the information we just entered plus two additional values:

A pattern to match certificate distinguished names.
A certificate.

These values are what we need in the next step.

Configuring the SAP Cloud Identity Services Tenant

You want your SAP Cloud Identity Services tenant to trust certificates generated by the SAP Continuous Integration and Delivery service. To enable that, login to the admin console of your tenant and navigate to "Tenant Settings > Authentication" > "Trusted Certificate Configuration". Click "Add".

For "Public Key", you can paste in the "Root Certificate" from the credential detail view. You can also paste any other valid certificate; it just does not matter.

The important value is the "Pattern". Paste in the pattern from the credential detail view. With the pattern the user email is extracted and the origin of the certificate (your SAP Continuous Integration and Delivery Service subscription) is checked. For more details on this, see the next section.

For more information, see the SAP Cloud Identity Service documentation.

Use the Certificate-based Credential in a Cloud Foundry Environment Job

The rest is routine. Either create a Cloud Foundry Environment job for you project or change an existing one to use you credential during the deployment. Here is an example for a deployment in the Acceptance stage:

That's it. Trigger your you job, lean back, and let the pipeline work for you.

Troubleshooting

In case the build fails with "Unauthorized" before the deployment, please log in to the admin console of your Cloud Identity Services tenant and navigate to "Tenant Settings" > Authentication" > "Certificate Authentication". Make sure that all check buttons are in OFF state.

Deep Dive

Short-lived Certificates

To achieve secure authentication without secret sharing, we use asymmetric cryptography in the form of certificates. Here are the details:

Your SAP Cloud Identity Services tenant trusts a certificate authority (CA) called "SAP Cloud Root CA". Each SAP operated service can issue certificates signed by that CA, which are subject to certain technically enforced rules.
The SAP Continuous Integration and Delivery service uses this in the following way. Let's assume we have a job that uses a "Certificate-based Authentication for Custom IdP" credential. When a build is triggered for this job, the following is going to happen:

A key pair and a certificate signing request (CSR) are generated.
The CSR is signed by the SAP Cloud Root CA.
The resulting certificate and the private key are injected into the environment of the triggered build, so that the build can use them to authenticate against your SAP Cloud Identity Services tenant.

Because there is a fresh certificate for every build, the validity of the certificate is extremely short: only twelve hours.

Validation of Certificate Distinguish Names

Now let's shift our point of view to the SAP Cloud Identity Services tenant which has just received a certificate in a request for authentication. It will do the following:

Using cryptography, it verifies that the certificate was issued by a trustworthy authority (the SAP Cloud Root CA)
Then, it looks into the fine print, i.e. the distinguished name (DN) of the certificate. It will be matched against the pattern configured above. The matching must be exact, except where a placeholder is used. The pattern will look similar to this:
CN=${mail}, L=CICD-c47ae4ee-59f4-4fcd-a692-7454ac9b71b7, OU=9abd6d5c-8ea7-49d4-ab08-a8dc776ada09, OU=SAP Cloud Platform Clients, O=SAP SE, C=DE

Let's look at the individual parts:
- OU=9abd6d5c-8ea7-49d4-ab08-a8dc776ada09, OU=SAP Cloud Platform Clients, O=SAP SE, C=DE: These values in the DN are enforce by the CA. The UUID is the subaccount ID of the SAP Continuous Integration and Delivery service. The presence of this ID means that only certificates from that service will be accepted.
- L=CICD-c47ae4ee-59f4-4fcd-a692-7454ac9b71b7: This value is provided by the SAP Continuous Integration and Delivery service. The UUID is the ID of the subaccount (owned by you) where your subscription to the service resides. This means that only certificates from this subaccount will be accepted.
- CN=${mail}: This is a placeholder to extract the email of the technical user. That email address was provided by you when you created the credential. In a later iteration, it will be possible to restrict the pattern also to a specific email address.

Summary

There are checks in place that ensure that only certificates are accepted which originate from your SAP Continuous Integration and Delivery service tenant.
The generated certificates are short lived. That makes cryptanalytic attacks almost impossible and mitigates the blast radius in case a private key and certificate pair gets compromised.
However, if at any point in time you suspect that something fishy is going on, there is a clean opt-out: Just delete the Trusted Certificate configuration from your Identity Service tenant.

Thanks for reading. I am happy for any kind of feedback, so let me know what you think!