App SSO Overview

App SSO is one of the great features offered in TAP, which has received a bunch of love in TAP 1.5 App SSO provides the needed APIs for curating and consuming a "Single Sign-On as a service" offering on Tanzu Application Platform.

Through App SSO, one can easily integrate TAP based workloads with SSO, in a secure, simple, and straightforward manner.

What’s new in TAP 1.5?

In TAP 1.5, App SSO has been enhanced with a few key new sets of functionality. The ones I am extremely excited about are:

1. New AuthServer CORS API
2. Role claim mapping from External IDP group membership
3. New default auth scopes for users

Let’s take a look at each of these features and what they bring to the table.

Auth Server CORS API

When working with SPAs and mobile apps with SSO, we need to configure CORS which is never a fun thing to deal with. Now, in TAP 1.5, we have a very simple and clean UX for defining CORS for Public Clients as part of the Auth Server CR.

With this new API, we can simply enable web apps, that utilize the PKCE authentication flow.

While TAP does support allowing all origins for CORS, it is not recommended to do so from a security perspective, and this should be done with great caution.

Let’s see what the UX looks like. The first step one would do is define the Auth Server as they would previously, just now you would add the CORS configuration:

kind: AuthServer
# ...
spec:
  cors:
    allowOrigins:
    - "https://vrabbi.cloud"
    - "https://*.vrabbi.cloud"

As can be seen, both exact matches, and wildcards are supported in the allowed origins array.

You could as mentioned allow all origins if needed as follows:

kind: AuthServer
metadata:
  annotations:
    sso.apps.tanzu.vmware.com/allow-unsafe-cors: ""
spec:
  cors:
    allowAllOrigins: true

As seen, we need to specify both in the config that we want all sources to be allowed, as well as with the allow-unsafe-cors annotation, as TAP does not want to prevent you from creating such a client, but wishes to deter you from doing so unless needed, as this is not a secure configuration and she be avoided when possible.

Once you have defined a Public Client, and an Auth Server with CORS enabled, you must set the authentication mode to none when creating the client registration as can be seen bellow:

kind: ClientRegistration
spec:
  clientAuthenticationMethod: none

This is needed as the Public Client flow is without authentication, and instead the PKCE flow will be utilized.

Role claim mapping from External IDP group membership

This new feature is another great enhancement, making App SSO much more user friendly.

This feature allows us to easily map and filter groups a user is a part of that are returned from the upstream IDP at login, into a set of roles, under the roles claim in the provided JWT token to your apps, which is provided by App SSO, and the relevant Auth Server.

This new feature supports 2 types of filters, for how to find the relevant groups in order to add the relevant roles. the 2 types are exactMatch and regex.

These 2 methods, enable just enough flexibility, while still keeping the API simple in my mind, and allow for us to map credentials from our upstream IDP, into our downstream apps, in a simple manner.

This feature is configured at the Auth Server level, per IDP. For example:

spec:
  identityProviders:
    - name: my-ldap
      ldap:
        roles:
          filterBy:
            - exactMatch: "admin-users"
            - regex: "^users-*"
    - name: my-oidc
      openid:
        roles:
          filterBy:
            - exactMatch: "admin-users"
            - regex: "^users-*"
    - name: my-saml
      saml:
        roles:
          filterBy:
            - exactMatch: "admin-users"
            - regex: "^users-*"

As can be seen, this is supported for OIDC, LDAP and SAML IDPs, making the configuration really simple and easy to integrate, no matter your setup.

Default Auth Scopes

This is a long requested feature, that is truly awesome to see being added. With this feature, you can now define authorization scopes that are automatically granted to all users from a specific IDP, regardless of their user role.

For example, given an AuthServer with an OIDC IDP configured, with defined authorization scope defaults:

kind: AuthServer
spec:
    identityProviders:
    - name: my-oidc
      openid:
        accessToken:
            scope:
                defaults:
                - "user.read"
                - "user.write"

With the above config, a client registration can be created, requesting the scopes:

kind: ClientRegistration
spec:
    scopes:
    - name: "roles"
    - name: "user.read"

Now that the client registration is added, when a Workload is registered by using the ClientRegistration, that workload, on behalf of the user, can request and be granted with the scope user.read automatically within the issued access token, without relation to the group memberships of that user.

This allows for some pretty powerful use cases, and i am excited to see where people take this.

Spring Cloud Gateway Integration

Another great feature, which is not new in TAP 1.5, but worth noting, is the simple integration one can do between Spring Cloud Gateway (SCG) and App SSO. The reason this is worth mentioning, is that in TAP 1.5, SCG is now included as an optional package, making the possibility of utilizing SCG much greater for a wider set of customers.

This is an area i expect to see grow over the next few releases, and it will be interesting to see how customers end up implementing these integrations and configurations in real world scenarios.

Summary

As you can tell, VMware have put a lot of effort into App SSO in this release, adding in key features which simplify the UX, and make the amount of customization needed in your own app to include SSO that much smaller, and easier to cope with, bringing us all a step closer to a more secure landscape, and better protected applications, which is always a huge benefit, especially when provided by a platform, with almost no overhead to manage!

In TAP 1.5, an amazing addition was made, with the inclusion of an additional package "Spring Cloud Gateway For Kubernetes"! This is a VMware product which was initially released in February 2021 as a standalone product, and is now included as part of TAP!

Spring Cloud Gateway for Kubernetes is based on the open source Spring Cloud Gateway project.

What Is Spring Cloud Gateway For Kubernetes

Spring Cloud Gateway for Kubernetes is based on the open source Spring Cloud Gateway project, and is targetted to be the API gateway solution that application developers love, and IT Operators are so happy that it exists! Spring Cloud Gateway for Kubernetes handles cross-cutting concerns on behalf of development teams, such as:

• Single Sign-On (SSO)
• access control
• rate limiting
• resiliency
• security SCG helps to accelerate API delivery using modern cloud native patterns, using any programming language you choose, and integration with your existing CI/CD pipeline strategy.

What Does SCG For Kubernetes Add On Top Of The Open Source Project

Beyond the upstream SCG capabilities, the SCG for Kubernetes offering, enhances the offering by integrating with other Spring ecosystem projects such as Spring Security and Spring Session.

Beyond these key additions, we also get additional features, only available in the commercial offering which include:

• Kubernetes native integration, using a set of CRDs, managed by the SCG for Kubernetes operator
• Dynamic API route configuration
• Support for API updates through existing CI/CD pipelines
• Simple SSO configuration
• Commercial API route filters to enable authentication and access control
• OpenAPI v3 auto-generated documentation
• Horizontal and Vertical scaling configuration, to reach High Availability and meet performance requirements

What Does the UX look like

The first step, after installing SCG from the TAP package repository, is to create a gateway instance, which can be as simple as:

apiVersion: tanzu.vmware.com/v1
kind: SpringCloudGateway
metadata:
  name: my-api-gateway
spec:
  count: 1

While this resource seems very simple, we can actually add a lot of logic here as well at the gateway level. a more advance setup may look more like this:

apiVersion: "tanzu.vmware.com/v1"
kind: SpringCloudGateway
metadata:
  name: my-advanced-api-gateway
  namespace: platform-ops-system
spec:
  api:
    serverUrl: https://my-advanced-api-gateway.example.com
    title: my advanced api gateway
    description: Micro Gateway to control internal APIs of my app
    version: 0.1.0
    cors:
      allowedOrigins:
        - api-portal.example.com
  count: 3
  sso:
    secret: sso-secret
  extensions:
    secretsProviders:
      - name: vault-jwt-keys
        vault:
          roleName: scg-role
    filter:
      jwtKey:
        enabled: true
        secretsProviderName: vault-jwt-keys   
  env:
    - name: spring.cloud.gateway.httpclient.connect-timeout
      value: "90s"
  healthCheck:
    enabled: true
    interval: 30s
  observability:
    tracing:
      wavefront:
        enabled: true
    metrics:
      wavefront:
        enabled: true
    wavefront:
      secret: wavefront-secret
      source: my-advanced-api-gateway
      application: my-app
      service: my-advanced-api-gateway
      prometheus:
        enabled: true
        serviceMonitor:
          enabled: true
          labels:
            release: my-advanced-api-prometheus"

As you can see, we can add a lot of logic in a gateway, and by abstracting it away from our applications, this makes everyone’s lives, so much easier!

Once we have a Gateway, we now need to define our routes. This is done in a separate CR called "SpringCloudGatewayRouteConfig". Lets see an example of what this may look like:

apiVersion: "tanzu.vmware.com/v1"
kind: SpringCloudGatewayRouteConfig
metadata:
  name: suppliers-routes-config
spec:
  service: 
    name: suppliers-api
  routes:
    - predicates:
        - Path=/list-outgoing-payments/
        - Method=GET
      filters:
        - RateLimit=2,10s
        - CircuitBreaker="suppliersCircuitBreaker,forward:/alternative-payments-service"
    - predicates:
        - Path=/process-payment/*/supplier/**
        - Method=POST,PUT,DELETE
      ssoEnabled: true

As you can see, we can easily define, based on many characteristics of a request, how it should be handled.

The upside of splitting the route configuration from the gateway is huge, because the configuration at the gateway level, are the platform and IT teams concerns, while the routes themselves, are what developers own. by splitting these concerns into separate APIs, we give a much cleaner boundry and seperation of concerns between the relevant teams in the organization.

The final resource we have is the glue that stiches this all together which is the 3rd and final CR added as part of SCG which is called "SpringCloudGatewayMapping".

This resource simply binds a route configuration to a specific gateway.

This would for example look like:

apiVersion: "tanzu.vmware.com/v1"
kind: SpringCloudGatewayMapping
metadata:
  name: suppliers-routes-mapping
spec:
  gatewayRef:
    name: my-advanced-api-gateway
    namespace: platform-ops-system
  routeConfigRef:
    name: suppliers-routes-config

The power we get with SCG for kubernetes is amazing, and having it in a kubernetes native implementation, allows us to manage our API Gateway configuration using industry standards such as GitOps. We also, because this is being defined as a kubernetes resource, can apply any policy tooling to enforce certain organizational requirements. for Example we could create OPA based policies using Tanzu Mission control, that dont allow any routes without SSO enabled, or we could require cirtuit breaker configs to exist for every route.

Summary

Having SCG for Kubernetes now at our fingertips when using TAP unlocks a wide range of advanced use cases, making the possibilities endless.

SCG also integrate with App Live View, allowing us to easily visualize the status of our metrics directly in TAP GUI alongside our applications themselves!

I am truly excited to see how organizations adopt this technology in their own paths to production, and make everyone’s lives easier, while at the same time, increasing security, application resilience, and visibility!

Application Accelerator Overview

App Accelerator helps you bootstrap developing your applications and deploying them in a discoverable and repeatable way.

You can think of app accelerator as a way to publish a software catalog to your end users, which will allow them to fill out a simple and customizable form, that will then generate a templated set of files which they can start iterating on for there new project.

Enterprise Architects author and publish accelerator projects that provide developers and operators in their organization ready-made, enterprise-conformant code and configurations.

App Accelerator, is based on the Backstage Software Template plugin, and enriches it with additional capabilities and features to make it extremely easy to use.

What Is New In TAP 1.5

With every release of TAP, we get some new and exciting features in App Accelerator, and this is very much the case in TAP 1.5!

There are 3 key new features in App Accelerator:

1. IntelliJ Plugin for App Accelerator
2. Accelerator Generated Projects Provenance
3. Global activation or deactivation of Git repo creation flow

Lets take a look at each of these features and what they bring to the table.

IntelliJ Plugin for App Accelerator

Just like we have had for a few releases in VSCode, we can now generate projects from accelerators, directly from Intellij!!!!

The flow is really great, as they have embedded the accelerator plugin in a way that makes it a seamless experience, just like creating a project using any other plugin in IntelliJ.

Let’s see what the flow looks like:

First, the developer opens IntelliJ and would select to create a new project:

Next, the developer select Application Accelerator on the left hand panel, and would select the relevant accelerator they want to use:

Next they would fill out the form of that accelerator:

Next they would review the inputs, and generate the project:

Finally, they would press create, and the new project will be opened for them automatically in IntelliJ!

As you can see, the flow is extremely intuitive, and flows very well with the current developer flow that they have, with all the additional benefits that application accelerators bring to the table included!

Accelerator Generated Projects Provenance

Provenance and attestation, are the new buzz words, and for good reason. With supply chain attacks happening day after day, we need a way of stating, where something was generated, how it was generated, by whom at is what generated, with what configuration settings etc.

Now in TAP 1.5, we are getting a new feature in Application Accelerators, which is enabled in all of the OOTB accelerators, and is easily implementable in all of your own custom accelerators, which will provide provenance for a project generated from an accelerator.

When you generate a project using an accelerator a new file accelerator-info.yaml is generated as part of the generated zip. If you choose to provision a git repo then this file is pushed along with other files in the generated zip.

Lets see an example file that is generated, and what it contains:

id: a572d705-1bb4-49ca-9164-2f8918548d01
timestamp: 2023-03-28T15:03:04Z
username: ScottRosenberg
source: VSCODE
accelerator:
  name: tanzu-java-web-app
  source:
    image: harbor.vrabbi.cloud/tap/tap-packages@sha256:28e34f0cbf0de2c6f317ea870caf21b79aa52a5359c28666a6ceec90184eb409
fragments:
  - name: build-wrapper-maven
    source:
      image: harbor.vrabbi.cloud/tap/tap-packages@sha256:195a3ca6585fa91c41292584a19c2807c72ecdf986ce860a7147451e89d467d4
  - name: java-version
    source:
      image: harbor.vrabbi.cloud/tap/tap-packages@sha256:fa976ccf1609cb69e74a0162f0f49581fd0d393003e2fbe5d54d12eae62b4ff9
  - name: tap-workload
    source:
      image: harbor.vrabbi.cloud/tap/tap-packages@sha256:dbf0dedb6848ad8a7704c1c19465a1ddae9039b0e63c1dd0df3e2ed9cbda6093
options:
  includeBuildToolWrapper: true
  javaVersion: 11
  projectName: tanzu-java-web-app
  repositoryPrefix: harbor.vrabbi.cloud/library/sample
  updateBoot3: false

Here we can see, that the project was generated via the VSCode plugin, by Scott Rosenberg, o0n March 28th 2023, using the Tanzu Java Web App accelerator which is coming from an imgpkg bundle with the exact SHA noted, which also invoked specific fragments which all are also defined in this case as imgpkg bundles, again with the exact SHA mentioned, and we also have the exact inputs I entered, available at the bottom of the file.

This type of provenance is extremely powerful, and I am really excited to see where this goes in future releases!

Global activation or deactivation of Git repo creation flow

One of the great features of Application Accelerator, is the ability to auto create a Git repository when i generate a new project.

While this is a great feature, some organizations do not want to expose this option. In cases where this functionality is not wanted, there is now an easy configuration that one can add to there TAP Values, under the tap_gui section which will disable this feature globally. This means it will disable the feature from both the IDE plugins as well as from TAP GUI itself.

To deactivate this feature, one simply needs to add the following YAML snippet to their TAP values file:

tap_gui:
  # Existing configuration .......
  app_config:
    # Existing configuration .......
    customize:
      # Existing configuration .......
      features:
        accelerators:
          gitRepoCreation: false

This will disable this feature globally, and align the platform to your environments needs, in a simple and easy way!

Summary

As you can see, VMware are putting a lot of effort into improving the Developer experience, and making the platform teams happy as well. These updates of Application Accelerator, are truly awesome to see, and I am even more excited to see what will become of these features in the future!

Background

TAP has always included a pluggable scanning mechanism allowing for the platform to perform source code and image scanning as part of your supply chain.

By default TAP utilizes Grype as the scanner, but has added support for additional scanner over time including:

1. Carbon Black Container Security – for image scanning
2. Snyk – for image scanning
3. Prisma Cloud (alpha) – for source code and image scanning

As I have many customers that use Aqua, as well as many customers that utilize Aquas open source scanner trivy, I was asked many times if TAP could integrate with these tools.

Back in November 2022, I started working on a trivy integration in TAP, and put together a POC implementation of trivy as a scanner for TAP.

This process was relatively very simple, and the results were pretty good, but i did not get around to building it for Aqua simply out of lack of time.

I ended up also writing a blog post describing what was needed in order to build the solution, with detailed instructions.

I also brought this up with the TAP team, as they are always extremely happy to get customer feedback, and they truly do listen to this feedback and take it seriously.

Trivy Scanner In TAP 1.5

Now in TAP 1.5, VMware have added a new Alpha scanner for Trivy which supports both the Opensource trivy scanner, as well as Aqua Enterprise, which is implemented using the Aqua plugin for trivy, making it a seamless change and experience between the OSS and Enterprise solutions.

Like the Prisma scanner which was added in TAP 1.4, The trivy scanner is released as an alpha feature, and is located in a seperate package repository.

While the second repository does require a few extra steps in terms of configuration, the benefit is huge, as these packages have lifecycles of there own, and as these are alpha integrations, bugs can occur. I found some issues for example in the Prisma scanner about a month ago, and let the relevant people know at VMware, and within 4 days, a new version was released, with updated documentation, and ready for consumption!

The scanner is extremely nice, in that we can not only scan with Aqua, but we also can have a scan policy resource, that instead of defining locally in each namespace what are policy around vulnerabilities is within a rego file, we can simply define a policy that checks if our scan results pass the Aqua scan policy defined globally within our Aqua console. This means that we can manage our scanning policies, and allow list and deny list of vulnerabilities, at the organizational level, without regard to where how and by whom an image was built.

Summary

It is great to see the new integrations of scanning solutions in TAP with every release, and Aqua + Trivy are truly an amazing addition to the already quite impressive list of integrations.

As these integrations mature, it will be great to see them fully integrated as well, as first class packages in the TAP package repository itself!