IBM Cloud Docs
Containerized apps with Ingress

Containerized apps with Ingress

With IBM Cloud® App ID, you can consistently enforce policy-driven security by using the Ingress networking capability in IBM Cloud Kubernetes Service. With this approach, you can enforce authentication and authorization policies for all the applications in your cluster at the same time, without ever changing your app code!

The Kubernetes Service custom Ingress image is deprecated as of 01 December 2020. This tutorial is updated to use the community Kubernetes Ingress image. To see the previous version of this documentation, see the Kubernetes Service documentation.

App ID Kubernetes integration architecture
Figure 1. App ID Kubernetes integration architecture

  1. A user opens your application and triggers a request to the web app or API.
  2. In the API flow, the Ingress controller attempts to validate the supplied tokens. If the web flow is used, it starts a three-leg OIDC authentication process.
  3. App ID begins the authentication process by displaying the login widget.
  4. The user provides a username or email and password.
  5. The Ingress controller obtains access and identity tokens from App ID for authorization.
  6. Every request that is validated and forwarded by the Ingress controller to your apps has an authorization header that contains the tokens.

Before you begin

Before you can get started, ensure that you have the following prerequisites.

  • An instance of App ID that is provisioned in the same region in which your cluster is deployed. The service name must contain only alphanumeric characters or hyphens (-), and cannot contain spaces.

  • A standard Kubernetes Service cluster with at least two worker nodes in each available zone.

  • The following IBM Cloud IAM roles:

    • Cluster: Administrator platform role
    • Kubernetes namespaces: Manager service role
    • App ID: Editor platform role and Writer Service role

  • The following CLIs:

  • The Kubernetes Service and Container Registry CLI plug-ins

To ensure the best performance of the integration, it is recommended that you always use the latest version of IBM Cloud Kubernetes Service Application Load Balancer (ALB). By default, autoupdate is enabled for your cluster. For more information about autoupdates, see OnDemand ALB update feature on Kubernetes Service.

Adding redirect URLs

A redirect URL is the callback endpoint of your app; the location where a user is sent after successfully signing in or out of your app. To prevent phishing attacks, App ID validates requested URLs against an allowlist of redirect URLs that you add to the service. By adding a URL to your allowlist, you give App ID permission to forward your users to that location. Learn more about redirect URIs.

  1. In the IBM Cloud console, select your instance of App ID from your resource list.

  2. Navigate to the Manage authentication page of your instance of App ID.

  3. In the Identity providers tab, be sure that an identity provider is set to on.

    If no provider is selected, the user is not authenticated, but is still issued an access token for anonymous access to the app.

  4. In the Authentication settings tab, add your redirect URLs and click the + symbol to save your changes. Your redirect URL should be formatted similarly to the following example:

    https://<hostname>/oauth2-<AppIDServiceInstanceName>/callback

    • Custom domain:

      A URL that is registered with a custom domain might look like: http://mydomain.net/myapp2path/oauth2-myappid/callback. If the apps that you want to expose are within the same cluster but in different namespaces, you can use a wildcard to specify all of them. This can be helpful during development, but it is recommended that you exercise caution when you use wildcards in production. For example, https://custom_domain.net/*/oauth2-myappid/callback

    • Ingress subdomain:

      If your app is registered with an IBM Kubernetes Ingress subdomain, your callback URL might look like: https://mycluster.us-south.containers.appdomain.cloud/myapp1path/oauth2-myappid/callback

Updating your Ingress resource

Your Ingress resource is used to define how you want to expose your applications. The resource contains the rules that define how to route incoming requests to your applications. To add App ID authentication to your apps, follow the steps in the IBM Cloud Kubernetes Service documentation.

Next steps

Now that your application is running in a Kubernetes cluster and Ingress is configured, you can try: