A Kubernetes controller/operator that manages service provider integration tasks.

• About
• Architecture
• Glossary
  • User
  • SPI Controller Manager
  • SPI OAuth Service
  • SPIAccessTokenBinding
  • SPIAccessToken
  • SPIFileContentRequest
• Administration Guide
  • Installation
  • Configuration
    • Common configuration parameters
    • Operator configuration parameters
    • OAuth service configuration parameters
  • Vault
  • Running
• User Guide
• Contributing
  • Building & Testing
    • Out of cluster
    • In cluster
  • Debugging
  • Manual testing with custom images
    • Requirements on the Service Providers
• License

The Service Provider Integration aims to provide a service-provider-neutral way (as much as reasonable) of obtaining authentication tokens so that tools accessing the service provider do not have to deal with the intricacies of obtaining the access tokens from the different service providers. The caller creates an SPIAccessTokenBinding object in a Kubernetes namespace where they specify the repository to which they require access and the required permissions in the repo. The caller also specifies the target Secret to which they want the access token to the repository to be persisted. The caller then watches the SPIAccessTokenBinding and reacts to its status changing by either initiating the provided OAuth flow or using the created Secret object. Additionally, SPI provides an HTTP endpoint for manually uploading the access token for a certain SPIAccessToken object. Therefore, the user doesn’t have to go through OAuth flow for tokens that they manually provide the access token for.

There are 2 main components. SPI HTTP API which is required for parts of the workflow that require direct user interaction and SPI CRDs (and a controller manager for them). The custom resources are meant to be used by the eventual Consumers of the secrets that require access tokens to communicate with service providers. Therefore, the main audience of SPI is the Consumers of the secrets. In the case of App Studio, this is most probably going to be HAS and/or HAC. Because SPI requires user interaction for a part of its functionality, HAC will need to interface with the SPI REST API so that authenticated requests can be made to the cluster and the service providers. SPI will not provide any user-facing UI on its own. Instead, for stuff that will need user interaction, it will provide links to its REST API that will either consume supplied data or redirect to a service provider (in case of OAuth flow).

A user is understood to have identity in the Kubernetes cluster and has some RBAC rules associated with it that gives it permissions to create at least SPIAccessTokenBinding and SPIAccessToken CRs. The user is also assumed to have identity in the service provider, such that there can be 1 or more service provider tokens associated with a single kubernetes identity.

The controller manager is in charge of reconciling the SPIAccessTokenBinding,SPIAccessToken,SPIAccessCheck, SPIFileContentRequest CRs.

The HTTP API of the OAuth Service is in charge of the parts of the workflow that require interaction with the user. E.g. initiating the OAuth flow to obtain the user token data or receive tokens supplied by the caller manually.

A CR that is basically a request for storing access token for certain repository with certain permissions as a secret within some namespace. SPI is not interested further in how such a secret is going to be consumed.

This CR represents the access token itself as a kubernetes object so that RBAC rules can be applied on it. Importantly this CR does not contain the token data, which is stored in Vault. The CR only contains metadata required to identify the token.

This CR represents a request to check repository accessibility.

This CR represents a request for content of the specific file in the given SCM repository.