Integrating Okta authentication with Tanzu Application Platform

Eknath -
Reading Time: 2 mins

Integrating Okta authentication with the Tanzu Application Platform (TAP) can provide several benefits for your application:

  1. Single Sign-On (SSO): Okta offers robust SSO capabilities, allowing users to authenticate once and gain access to multiple applications seamlessly. With TAP and Okta integration, users can log in to TAP and access their authorized applications without the need for separate authentication for each application.
  2. Centralized Identity and Access Management (IAM): Okta serves as a centralized identity and access management system, enabling you to manage user identities, roles, and permissions in a unified manner. By integrating Okta with TAP, you can leverage Okta’s IAM features to control access to your applications hosted on TAP and manage user provisioning and deprovisioning efficiently.
  3. Enhanced Security: Okta provides robust security features such as multi-factor authentication (MFA), adaptive authentication, and contextual access policies. By integrating Okta with TAP, you can leverage these security capabilities to strengthen the authentication and access control mechanisms of your applications.
  4. User Lifecycle Management: Okta offers user lifecycle management capabilities, allowing you to automate user onboarding, offboarding, and user attribute synchronization across applications. By integrating Okta with TAP, you can streamline user management processes, ensuring that users have appropriate access to TAP-hosted applications based on their roles and permissions.
  5. Developer-Friendly Integration: Okta provides developer-friendly APIs, SDKs, and extensive documentation, making it easier to integrate Okta authentication with your applications on TAP. Okta supports industry-standard protocols such as OAuth 2.0 and OpenID Connect, allowing you to leverage these standards for secure and seamless authentication.
  6. Scalability and Reliability: Tanzu Application Platform offers scalability and reliability for deploying and managing cloud-native applications. By integrating Okta with TAP, you can leverage the scalability and reliability of both platforms, ensuring that your applications can handle increasing user loads while providing a seamless authentication experience.
kubectl create secret generic routesecret --namespace=pinniped-supervisor --from-literal=secret-access-key=<Access Key>
---
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-staging
  namespace: cert-manager
spec:
  acme:
    email: "<mail id>"
    privateKeySecretRef:
      name: letsencrypt-staging
    server: https://acme-v02.api.letsencrypt.org/directory
    solvers:
    - selector:
        dnsZones:
          - "vmwareexploreindia.com"
      dns01:
        route53:
          region: ap-south-1
          accessKeyID: <Access Key>
          secretAccessKeySecretRef:
            name: "routesecret"
            key: "secret-access-key"
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: pinniped-supervisor-cert
  namespace: pinniped-supervisor
spec:
  secretName: pinniped-supervisor-tls-cert
  dnsNames:
  - "pinniped-supervisor.auth.vmwareexploreindia.com"
  issuerRef:
    name: letsencrypt-staging
    namespace: cert-manager
    kind: ClusterIssuer
---
apiVersion: v1
kind: Service
metadata:
  name: pinniped-supervisor
  namespace: pinniped-supervisor
spec:
  type: LoadBalancer
  ports:
  - name: pinniped-supervisor
    port: 443
    protocol: TCP
    targetPort: 8443
  selector:
    app: pinniped-supervisor
apiVersion: idp.supervisor.pinniped.dev/v1alpha1
kind: OIDCIdentityProvider
metadata:
  namespace: pinniped-supervisor
  name: okta
spec:
  # Specify the upstream issuer URL associated with your auth0 application.
  issuer: https://trial-3063355.okta.com ## Replace with your Okta Issuer url

  # Specify how to form authorization requests.
  authorizationConfig:
    additionalScopes: [offline_access, groups, email]
    allowPasswordGrant: false

  # Specify how claims are mapped to Kubernetes identities. This varies by provider.
  claims:
    username: email
    groups: groups

  # Specify the name of the Kubernetes Secret that contains your
  # application's client credentials (created as follows).
  client:
    secretName: okta-client-credentials

---
apiVersion: v1
kind: Secret
metadata:
  namespace: pinniped-supervisor
  name: okta-client-credentials
type: secrets.pinniped.dev/oidc-client
stringData:
  clientID: "<Client ID of Okta Application>"
  clientSecret: "<Client secret of Okta Application>"

---
apiVersion: config.supervisor.pinniped.dev/v1alpha1
kind: FederationDomain
metadata:
  name: pinniped-supervisor-federation-domain
  namespace: pinniped-supervisor
spec:
  issuer: "https://pinniped-supervisor.auth.vmwareexploreindia.com"
  tls:
    secretName: pinniped-supervisor-tls-cert
kubectl get secret pinniped-supervisor-tls-cert -n pinniped-supervisor -o 'go-template={{index .data "tls.crt"}}'
---
apiVersion: authentication.concierge.pinniped.dev/v1alpha1
kind: JWTAuthenticator
metadata:
  name: pinniped-jwt-authenticator
spec:
  issuer: "https://pinniped-supervisor.auth.vmwareexploreindia.com"
  audience: concierge
  tls:
    certificateAuthorityData: "<ca - crt>"