Managing SSO for applications is a complex task, and since TAP 1.4, we have had a great feature called AppSSO, which is aimed at helping make the story of SSO integration much easier for developers and operators.

In TAP 1.6, a major effort was put into AppSSO to make it even more streamlined, and simple to use, while also exposing some more new advanced features, which can be very handy when needed.

In TAP 1.6 the main changes in AppSSO include:

1. Cluster Workload Registration Class
2. Cluster Unsafe Test Login
3. Custom Claim Mappings
4. Configurable token expiry settings

Lets go over what each of these improvement entails and what use cases they can help with.

Cluster Workload Registration Class

This integration is extremely exciting to see. With this new API, we can easily integrate AppSSO with Crossplane and the Services Toolkit components to allow for dynamic service provisioning of OIDC clients from an auth server!

It exposes an AuthServer as a ready-to-claim AppSSO service offering, making it really easy for developer to create new clients for an auth server on demand!

When you create a ClusterWorkloadRegistrationClass (cwrc) resource, this will create behind the scenes a Crossplane Composition and a Services Toolkit ClusterInstanceClass.

The composition itself templates out a new CRD which is also part of this new offering caller a WorkloadRegistration.

While in the past we had the ClientRegistration API, the new API, is more portable, and easily can be promoted between environments without changes to the spec, supporting a GitOps approach which is always the preferred approach in the Kubernetes world.

As we have the ability via the service toolkit to limit permissions to users, for specific classes, and each cwrc creates a new class which is tied to a specific auth server, we can easily manage RBAC and permission boundaries for different IDPs we use, in multi tenant scenarios, while still providing a simple and clean UX for a self service offering to our developers which is awesome!

While more complex and advanced feature can be added, lets take a look at a simple example of what this could look like:

apiVersion: sso.apps.tanzu.vmware.com/v1alpha1
kind: ClusterWorkloadRegistrationClass
metadata:
  name: dev-sample
spec:
  base: 
    spec:
      authServerSelector:
        matchLabels:
          env: dev

apiVersion: services.apps.tanzu.vmware.com/v1alpha1
kind: ClassClaim
metadata:
  name: dev-sample-01
spec:
  classRef:
    name: dev-sample
  parameters:
    workloadRef:
      name: my-workload
    redirectPaths:
      - /redirect/uri

As you can see, the new API is extremely simple to use and understand, and can open up some amazing opportunities for offering a truly self service SSO offering to your end users.

While this is great for production, and more advanced setups, in dev environments or POCs, we often simply want something that just works. The above APIs are simple, but still require configuring the auth server and understanding more low level details than we want to deal with in dev environments. This is where the next new feature comes in.

Cluster Unsafe Test Login

This new API is the recommended way to get started with AppSSO in non production environments.

The new CRD ClusterUnsafeTestLogin (cutl) is so simple, it does not even have a spec!

the only element which is configurable is the name.

apiVersion: sso.apps.tanzu.vmware.com/v1alpha1
kind: ClusterUnsafeTestLogin
metadata:
  name: demo

When you apply the above resource to a cluster, a few things will be created for you. First an Auth Server with an internal unsafe IDP will be deployed. next a token signing key will be generated, and finally a ClusterWorkloadRegistrationClass (cwrc) will be created, which will in turn create a ClusterInstanceClass and a Composition as mentioned above.

The auth server is configured in this setup with an http only issuer URI and allows all CORS origins. While this is definitely not a production setup, it makes integrating into your apps much easier, and removes all of the auxiliary issues from the time of development, making it much easier to get started, and to make sure the SSO elements are working for you as expected, and then you can switch to a more production ready setup, with a real backing IDP, more secure CORS configurations and of course TLS only communication.

The auth server which gets deployed as part of a CUTL, includes a single user with the username “user” and the password “password”.

Once you apply a CUTL resource, you can then create a class claim just like with a CWRC as seen above.

apiVersion: services.apps.tanzu.vmware.com/v1alpha1
kind: ClassClaim
metadata:
  name: dev-sample-01
spec:
  classRef:
    name: demo
  parameters:
    workloadRef:
      name: my-workload
    redirectPaths:
      - /redirect/uri

This new API truly makes getting started on integrating SSO into you apps a breeze, and makes the barrier of entry to AppSSO so much lower!

While these past 2 features focused on simplifying the API and consumption of AppSSO, the next 2 improvements are for more advanced use cases, but are truly amazing to see, and actually can be game changers in certain environments.

Lets take a look at the one I am most excited about which is custom claim mappings support!

Custom Claim Mappings

With this new capability, service operators can control which claims appear in an Auth Server issued ID Token, and how to obtain this value from an upstream identity provider.

Recently when working on a project where i needed to test 4 different OIDC providers, i learned that the 4 claims which this specific app needed, only one of them was the same accross the different OIDC providers. While all data was there, every provider named their claims differently (group / groups / group_names / Groups), (full_name, name, fn, Full_Name) and so on.

While this may seem like a simple issue to solve, it actually is not easy, as within an application i need to look at a specific field in an ID Token to extract the data i need to know who this user is, and what permissions they should have.

This issue gets even more complex when working with an upstream IDP which is not OIDC based, such as LDAP or SAML.

With this new feature, we can now at the Auth Server level, perform mappings between upstream fields, and the claims on the Auth Server generated tokens!

for example, if i want to standardize on the name “groups” for my groups claim, yet i am using workspace one which provides this data as “group_names”, i can simply set the following in my Auth Server:

spec:
  identityProviders:
  - name: wso-idp
    openid:
      idToken:
        claims:
          - fromUpstream: "group_names"
            toClaim: "groups"

This simple yet extremely powerful feature is a huge boost to the AppSSO tooling which opens up awesome opportunities for integrations.

While the above works for external IDPs such as OIDC, LDAP and SAML, the configuration for internal unsafe IDPs in an auth server is a bit different, but also easy to configure.

spec:
  identityProviders:
    - name: test-users
      internalUnsafe:
        users:
          - username: joe
            password: "password"
            roles:
              - "dev"
            claims:
              given_name: "joe"
              family_name: "rosenberg"
              middle_initial: "A"
              email: "joe@vrabbi.cloud"
              alt_address: "123 Awesome Street"
          - username: wendy
            password: "password"
            roles:
              - "operator"
            claims:
              alt_address: "456 Cool Street"
              middle_initial: "T"

As you can see here, we simply configure per user, the custom roles and claims they should have in their ID tokens. With this ability, we can easily simulate real world test cases, even when using an internal unsafe IDP!

There is one more new feature in AppSSO in TAP 1.6, which while it may sound less interesting and exciting, it makes the offering more secure and more tunable to whatever your security teams requirements are.

Token Expiry Settings

In TAP 1.6, we now have the ability to configure the token expiry settings at a per auth server level for access, id, and refresh tokens.

The default expirations set by AppSSO are 12 hours for access and id tokens, and 30 days for refresh tokens.

In order to configure these settings, you just need to add the following to your auth server manifest:

spec:
  token:
    accessToken:
      expiry: "5m"
    idToken:
      expiry: "5m"
    refreshToken:
      expiry: "8h"

The time durations can be provided in seconds (s), minutes (m), or in hours (h). this means that for example the default 30 days for refresh tokens is actually set as “720h”.

Summary

As can be seen, a lot of effort was put into AppSSO in this release, making the integration tasks easier and more streamlined, and also improving on the capability set, and adding new and improved functionality to help all personas involved.

I’m really excited about these new features and can’t wait to see them being used in the wild!

The Metadata Store has been a key element in a secure supply chain within TAP since the GA of TAP, and it provides a central location where all CVE data and SBOMs are stored for our source code and images.

In TAP 1.6, we get a great new set of functionality in the metadata store, allowing for us to now have vulnerability reports stored per build and not just a single report per workload image.

This new feature can be extremely beneficial, as it allows us to perform queries and figure out in which version a specific vulnerability was first introduced, as well as a really great ability to understand which CVEs TBS for example with new dependencies was able to solve for us without the need to change anything in our source code!

The aggregated report is not gone, we simply now also have per build reports, giving us the best of all worlds!

While this may seem like a small feature, it actually truly is huge, and is a huge milestone down the path to being able to perform full end to end tracability and attestation for our supply chains, as well as providing a clear and simple API to be able to gain truly important insights on the development flows within our organization.

This new functionality, combined with the new data being included in the Metadata Store DB via AMR, can open up endless opportunities for data driven decision making and reporting for TAP, which simply has not been possible till today.

Summary

While this new functionality is API/CLI accessible only today, I truly hope to see this integrated into a UI flow in a future release, where we could do diffs between reports of an image and gain clear visibility of the changes between specific image builds in a clear and concise manner!

TAP has many features which help with securing our software supply chain.

One of the key elements of security is obviously source code and image scanning which TAP has had since GA, but as we all know, finding the vulnerabilities is one thing, but how to triage these found vulnerabilities is an entire beast in it of itself, and this is actually where a lot of the true pain lies.

As per the documentation:

The new Triage feature of Tanzu Application Platform allows you to store vulnerability analysis information alongside the current data handled by SCST – Store. Using the Tanzu Insight CLI, users can now perform basic triaging functions against any detected vulnerabilities. The main objective is to reduce spreadsheet and tool toil by centralizing CVE scanning, identification, and triaging in one place.

While the current flow is documented as a purely CLI based flow, using the insight plugin for Tanzu CLI, because this is also a fully API driven flow, Hopefully we will see this flow also integrated into a UI based flow in a future release.

Currently this is an experimental feature, and will likely change over time as the feature gets more and more usage and feedback from customers, but the idea in it of itself is extremely powerful, and testing it out and providing feedback is a great way to influence the future of the product in this area!

What does the flow look like

The first step when beginning to triage a new vulnerability, is to find which CVE we are going to triage, and for which image and workload.

tanzu insight triage update \
  --cveid $CVE_ID \
  --pkg-name $PKG_NAME \
  --pkg-version $PKG_VERSION \
  --img-digest $IMG_DIGEST \
  --artifact-group-uid $WORKLOAD_UID \
  --state in_triage

tanzu insight triage update \
  --cveid $CVE_ID \
  --pkg-name $PKG_NAME \
  --pkg-version $PKG_VERSION \
  --img-digest $IMG_DIGEST \
  --artifact-group-uid $WORKLOAD_UID \
  --state not_affected \ 
  --justification requires_environment \
  --response workaround_available \
  --comment "This is only exploitable on ARM based processors and we run all K8s on x86 processors"

Beyond the basic flow from above, we can also list all CVE triages and there status using the triage list command, as well as copy triage data between images easily using the triage copy command.

Summary

While this is only a CLI flow, and the UX is still a bit rough, the idea and promise of a solution like this is huge, and it is great to see the direction the TAP team are taking, going beyond just alerting that a vulnerability exists, but trying to assist customers in how to build workflows and processes in order to start to tackle the vulnerabilities found in an organized, and central manner!

I’m very excited to see this mature over time, and to see where this ends up evolving over the next few releases!

The new scanning model “Supply Chain Security Tools – Scan 2.0” which was introduced back in TAP 1.5, now includes some great new improvements, and has been promoted from Alpha to Beta!

The new model, is much easier to extend and customize to your own organizations needs, and is built with a more scalable and secure architecture.

In the previous model of the scanning feature in TAP, image scanning definitions needed to handle 4 main topics:

1. Perform the scan
2. Output an SBOM in CycloneDX or SPDX format
3. Push the data to the central metadata store
4. validate the scan results against your desired security policy

Now with this new model, the image scanning definition is only responsible for scanning the image and outputting an SBOM with the results in CycloneDX or SPDX formats. From their the platform will handle the rest by pushing the SBOM to an OCI registry, and then the AMR Observer will pull down this data and transfer it via CloudEvents to the AMR Persister which will save the data in the Metadata Store.

With TAP 1.6, we now have the ability to easily integrate the new scanning mechanism in the OOTB testing and scanning supply chain, and we also get visibility into the results from the scans in the Tanzu Developer Portal (TDP) formerly known as TAP GUI.

The new mechanism is based on a CRD called ImageVulnerabilityScan (IVS) which you define in your cluster, and sample IVS templates are provided in the docs for Grype, Trivy, Prisma, Snyk and Carbon Black.

Summary

The new Scanning framework is really looking great, and the functionality while not yet feature parity with the initial framework, does provide alot of benefits.

The main lacking currently, is the lack of ScanPolicy support. One other key lacking in the new model so far, is that it only covers image scanning at this point, and does not cover source code scanning.

Source code scanning has also been removed from the OOTB supply chains in this version, but can be re-integrated if you need that functionality.

While the Source Code scanning in TAP was never great, hopefully VMware will add back this functionality in a new and more feature rich manner by integrating with common SAST and DAST solutions which would suite the needs of TAP workloads much better.