App Connect

As part of the IBM App Connect Operator 1.5.0 release and its associated 12.0.1.0-r1 operand, we are introducing the ability for an integration server to obtain BAR files from a location other than a content server.

In previous releases, two main mechanisms are available for providing BAR files to integration servers:

• The ability to upload a BAR file to the App Connect Dashboard and then obtain a "BarURL" to the BAR file either via the create wizard or from the "BAR files" management page. The integration server then uses the BarURL value to download the BAR file on startup and process the applications appropriately. This experience is UI led, does not have an API option available, and is also limited to one BAR file per integration server.
• The ability to build a custom image that contains all the configuration for the integration server, including all the BAR files or applications that are required. The custom image is then referenced in the IntegrationServer custom resource (CR) and loaded appropriately.

We are now extending the use of the BarURL field (or spec.barURL parameter) to allow integration servers to also accept external HTTPS endpoint locations that support basic or alternative authentication. This means that if you are building a continuous integration and continuous deployment (CICD) pipeline, you can build your BAR file and add it to a repository system such as Artifactory. You can then directly reference the BAR file in your IntegrationServer CR without the need to manually upload the file to the Dashboard, or build a custom image.

In addition to extending the BarURL field, we have also introduced a new configuration type called `barauth`, which you can use to provide the credentials for connecting to the external endpoint where your BAR files are stored. Your IntegrationServer CR must reference a configuration object of type `barauth` if you are using an external endpoint.


We now also provide support for multiple co-related BAR files in the BarURL field by using a comma-separated list. Note that all the BAR files must use the same credentials.

Worked Example

1 - Defining basic authentication credentials for connecting to an endpoint

Create a Configuration resource of type barauth, which contains the username and password to your endpoint. First, create the JSON content that contains the appropriate credentials:

{"authType":"BASIC_AUTH","credentials":{"username":"fakeuser@uk.ibm.com","password":"fakePassword"}}

Next, Base64-encode this content to enable it to be embedded in the Configuration resource:

echo '{"authType":"BASIC_AUTH","credentials":{"username":"fakeuser@uk.ibm.com","password":"fakePassword"}}' | base64

Finally, define the Configuration resource values by using YAML code such as this. Note that **spec.data** is used to specify the generated Base64-encoded value.

apiVersion: appconnect.ibm.com/v1beta1
kind: Configuration
metadata:
name: artifactory-creds
namespace: ace
spec:
type: barauth
description: Credentials for Artifactory
data: eyJhdXRoVHlwZSI6IkJBU0lDX0FVVEgiLCJjcmVkZW50aWFscyI6eyJ1c2VybmFtZSI6ImZha2V1c2VyQHVrLmlibS5jb20iLCJwYXNzd29yZCI6ImZha2VQYXNzd29yZCJ9fQo=

This example results in a new configuration object called artifactory-creds. If you look at the resource YAML code, you'll see that it's been updated with a new field called `secretName`, which is a reference to the secret that now contains your credentials.

2 - Deploying BAR files from the endpoint to an integration server

Creating the integration server is now very simple with only three extra steps required:
1. Provide URLs to one or more BAR files that can be accessed by using the same credentials.
2. Reference your "barauth" configuration object in your IntegrationServer CR.
3. (Optional) If you want to use the App Connect Dashboard with your integration server, set createDashboardUsers: true.

The following example shows an IntegrationServer CR that is configured to use two external BAR files:

apiVersion: appconnect.ibm.com/v1beta1
kind: IntegrationServer
metadata:
name: is-01-toolkit
namespace: ace
spec:
license:
accept: true
license: L-KSBM-BZWEAT
use: AppConnectEnterpriseProduction
version: '12.0'
barURL: https://artifactory.com/myrepo/getHostnameAPI.bar,https://artifactory.com/myrepo/CustomerDatabaseV1.bar
configurations:
- artifactory-creds
createDashboardUsers: true

3 - Specifying alternative authentication credentials for the endpoint

There are a number of alternative credentials that can be specified in the JSON content for a "barauth" configuration.

No authentication

To connect to an endpoint that does not have basic authentication enabled, you can supply a blank username and password as shown in the following JSON example:

{"authType":"BASIC_AUTH","credentials":{"username":"","password":""}}


Insecure

If you want to connect to a website that presents an invalid certificate, you can ignore certificate errors by setting insecureSsl to true as in the following JSON example:

{"authType":"BASIC_AUTH","credentials":{"username":"fakeuser@uk.ibm.com","password":"fakePassword","insecureSsl":"true"}}


CaCerts

If your endpoint is secured by an untrusted certificate authority (CA) such as a corporate CA, the CA certificate can be provided by using a caCert setting. To specify the certificate in a JSON-compliant format, you must first convert it to a single line by using your preferred tooling. For example, the following command will convert and then output the .pem file content as a single line:

awk 'NF {sub(/\r/, ""); printf "%s\\n",$0;}' caCert.pem

You can then embed this output in the configuration JSON as shown in the following example:

{"authType":"BASIC_AUTH","credentials":{"username":"fakeuser@uk.ibm.com","password":"fakePassword","caCert":"-----BEGIN CERTIFICATE-----\nMIIDmzCCAoOgAwIBAgIUbHjZL70/Qs42iomAGIlIRasnLjswDQYJKoZIhvcNAQEL\nBQAwXTELMAkGA1UEBhMCVUsxEDAOBgNVBAgMB0h1cnNsZXkxEDAOBgNVBAcMB0h1\ncnNsZXkxDDAKBgNVBAoMA0lCTTEcMBoGCSqGSIb3DQEJARYNaGVyZUB0aGVyZS5v\nbTAeFw0yMTA1MDcxMDAwMjVaFw0yNjA1MDYxMDAwMjVaMF0xCzAJBgNVBAYTAlVL\nMRAwDgYDVQQIDAdIdXJzbGV5MRAwDgYDVQQHDAdIdXJzbGV5MQwwCgYDVQQKDANJ\nQk0xHDAaBgkqhkiG9w0BCQEWDWhlcmVAdGhlcmUub20wggEiMA0GCSqGSIb3DQEB\nAQUAA4IBDwAwggEKAoIBAQDDCKVMjw7h35G8QkU8vqtnsO0lk8aaRPli4pVTCYJ5\nfonvdxndDkwMFlXf0e6gZ2qi1rEK/l/2jgW1uhcbybdWZHKx9jwvRfPSizJEBve/\nJJdR7uCkkGRjlEWuGHEiNVxaPxrhUuG0TKsmVETl4b/kwDRdv2TcbxZeAFcOnE4a\ni6FGtSzQRxXOubekfhNcw7Nvgvu7T8MzqMTqheHRh2ayPbi4B3X/Zbj7NbXqTvF5\nD16Uf/ddwz5UWRkvN1knTNgkNJvf08Oh3SfjAE2iJ5xlI1GIGbtxwUOZ4miBefYi\n/vOXBUbsWEeloFaRuYrkG06oJ4hZQyjZQ7VRtCtApwenAgMBAAGjUzBRMB0GA1Ud\nDgQWBBR0rm3YGM5NJEIR9Rvlds0tRpOf3DAfBgNVHSMEGDAWgBR0rm3YGM5NJEIR\n9Rvlds0tRpOf3DAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQCm\n7rXTwv32AMTBPiKjJrEw+TKicPLRvjlfv8Ris1GCWKAJyNTmBX2NBGL8WimmYgKa\nMf3uG5Hx4r8rIlQ5g5GBWboBWP7oo+NKnc+DscNEAKr5iaX55wtlR9hoN85M9LvR\naxjpTjMdsAo9rk9Ct/jBHCjr3zTQkc1K00/63ujkm/jf/ychXBrCPTy0Iwm3k8hn\nsQ6SG0k6tFjL9HnuNxS67AOfRjWaFtWJsIZzkE/4qxkcQQlberX2SSwUsCOD8FCQ\nQw1ZcBtU51kvLDjmDtRdDilnjvoI+tMBQle47+baHA/1Z1e95yna7q4mtnUNKuFH\n2DFKwraLcQqQVeT1Fa/I\n-----END CERTIFICATE-----\n"}}


CaCerts via secret

It's also possible to supply the CA certificate via a secret by using a caCertSecret setting. To begin, create a Secret resource that specifies the certificate content in the ca.crt` field. The secret must also be of type kubernetes.io/tls as shown in the following sample YAML code:

kind: Secret
apiVersion: v1
metadata:
name: robscacert
namespace: ace
data:
ca.crt: >-
LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURtekNDQW9PZ0F3SUJBZ0lVYkhqWkw3MC9RczQyaW9tQUdJbElSYXNuTGpzd0RRWUpLb1pJaHZjTkFRRUwKQlFBd1hURUxNQWtHQTFVRUJoTUNWVXN4RURBT0JnTlZCQWdNQjBoMWNuTnNaWGt4RURBT0JnTlZCQWNNQjBoMQpjbk5zWlhreEREQUtCZ05WQkFvTUEwbENUVEVjTUJvR0NTcUdTSWIzRFFFSkFSWU5hR1Z5WlVCMGFHVnlaUzV2CmJUQWVGdzB5TVRBMU1EY3hNREF3TWpWYUZ3MHlOakExTURZeE1EQXdNalZhTUYweEN6QUpCZ05WQkFZVEFsVkwKTVJBd0RnWURWUVFJREFkSWRYSnpiR1Y1TVJBd0RnWURWUVFIREFkSWRYSnpiR1Y1TVF3d0NnWURWUVFLREFOSgpRazB4SERBYUJna3Foa2lHOXcwQkNRRVdEV2hsY21WQWRHaGxjbVV1YjIwd2dnRWlNQTBHQ1NxR1NJYjNEUUVCCkFRVUFBNElCRHdBd2dnRUtBb0lCQVFERENLVk1qdzdoMzVHOFFrVTh2cXRuc08wbGs4YWFSUGxpNHBWVENZSjUKZm9udmR4bmREa3dNRmxYZjBlNmdaMnFpMXJFSy9sLzJqZ1cxdWhjYnliZFdaSEt4OWp3dlJmUFNpekpFQnZlLwpKSmRSN3VDa2tHUmpsRVd1R0hFaU5WeGFQeHJoVXVHMFRLc21WRVRsNGIva3dEUmR2MlRjYnhaZUFGY09uRTRhCmk2Rkd0U3pRUnhYT3ViZWtmaE5jdzdOdmd2dTdUOE16cU1UcWhlSFJoMmF5UGJpNEIzWC9aYmo3TmJYcVR2RjUKRDE2VWYvZGR3ejVVV1Jrdk4xa25UTmdrTkp2ZjA4T2gzU2ZqQUUyaUo1eGxJMUdJR2J0eHdVT1o0bWlCZWZZaQovdk9YQlVic1dFZWxvRmFSdVlya0cwNm9KNGhaUXlqWlE3VlJ0Q3RBcHdlbkFnTUJBQUdqVXpCUk1CMEdBMVVkCkRnUVdCQlIwcm0zWUdNNU5KRUlSOVJ2bGRzMHRScE9mM0RBZkJnTlZIU01FR0RBV2dCUjBybTNZR001TkpFSVIKOVJ2bGRzMHRScE9mM0RBUEJnTlZIUk1CQWY4RUJUQURBUUgvTUEwR0NTcUdTSWIzRFFFQkN3VUFBNElCQVFDbQo3clhUd3YzMkFNVEJQaUtqSnJFdytUS2ljUExSdmpsZnY4UmlzMUdDV0tBSnlOVG1CWDJOQkdMOFdpbW1ZZ0thCk1mM3VHNUh4NHI4cklsUTVnNUdCV2JvQldQN29vK05LbmMrRHNjTkVBS3I1aWFYNTV3dGxSOWhvTjg1TTlMdlIKYXhqcFRqTWRzQW85cms5Q3QvakJIQ2pyM3pUUWtjMUswMC82M3Vqa20vamYveWNoWEJyQ1BUeTBJd20zazhobgpzUTZTRzBrNnRGakw5SG51TnhTNjdBT2ZSaldhRnRXSnNJWnprRS80cXhrY1FRbGJlclgyU1N3VXNDT0Q4RkNRClF3MVpjQnRVNTFrdkxEam1EdFJkRGlsbmp2b0krdE1CUWxlNDcrYmFIQS8xWjFlOTV5bmE3cTRtdG5VTkt1RkgKMkRGS3dyYUxjUXFRVmVUMUZhL0kKLS0tLS1FTkQgQ0VSVElGSUNBVEUtLS0tLQ==
tls.crt: ''
tls.key: ''
type: kubernetes.io/tls

Next, provide the name of the generated secret as the caCertSecret value as shown in the following JSON example:

{"authType":"BASIC_AUTH","credentials":{"username":"fakeuser@uk.ibm.com","password":"fakePassword","caCertSecret":"robscacert"}}
#AppConnect
#Integration
#integrationservers