Spinnaker – Authentication

Docs: LDAP

Mon, 01 Jan 0001 00:00:00 +0000

Lightweight Directory Access Protocol (LDAP) is a standard way many organizations maintain user credentials and group memberships. Spinnaker uses the standard “bind” approach for user authentication. This is a fancy way of saying that Gate uses your username and password to login to the LDAP server, and if the connection is successful, you’re considered authenticated. Note that there is a fair bit of crossover between the authorization and authentication settings.

Notes

This is mostly a spring configuration around LDAP handling. As such, many issues may be documented on spring on configuration values for your needs.
If the manager Domain Name (DN) is NOT set, all searches attempt to use the user currently logging in. You’ll often see errors in the log files tied to “bind failures” and LDAP error codes.
Escaping things like spaces is handled by the library. You do NOT need to use LDAP escape codes to handle spaces.
We highly suggest the use of SSL for the LDAP connection (ldaps://...). Otherwise, user passwords are passed in clear text over the wire.
Ports commonly used or referenced:
- 636 - LDAP with SSL (ldaps)
- 389 - LDAP
- 3268 - Active Directory (AD) Global Directory non-SSL port
- 3269 - AD Global Directory SSL port

When a port is not specified, ldap://host/whatever implies port 389 by default. ldaps://host/whatever uses port 636 by default.

How to determine the “User DN”

Extract the Root DN from the url (ldaps://my.server/a/b/c → a/b/c)
- If com.netflix.spinnaker.fiat.roles.ldap.LdapUserRolesProvider log level is at debug, you should see Root DN: <the actual root DN extracted>
If userSearchFilter is set:
- Search LDAP:
  - Search in userSearchBase OR the root (would be a/b/c in this example) if userSearchBase is not set.
  - Filtered by userSearchFilter="(d={0})" where uid=<the username as typed in>, such as jdoe.
  - Start at the rootDn and use sub tree searches
- Return root DN computed + the found user DN
If userSearchFilter is not provided:
- Calculate the user DN using userDnPattern. In the case below, the user jdoe would have a full DN of uid=jdoe,ou=users,dc=mydomain,dc=net.
- Return root DN computed + user DN

For example, given the following parameters:

Root DN is dc=my-organization,dc=com
userDnPatternn is uid={0},ou=users
User with the id jdoe

The full, unique DN would be uid=jdoe,ou=users,dc=my-organization,dc=com.

When jdoe is trying to log in, this full user DN is constructed and passed to the LDAP server with their password. The server hashes the password and compares it to its own hashed version. If successful, the bind (aka connection) is successful and Gate creates a session.

Testing with ldapsearch

In the above example, you could test with:

//Search using manager DN, manager password on url with base of "X"
# When: userSearchFilter=(uid={0}) userSearchBase=DC=USERS,OU=Y,O=io 
ldapsearch -D "MANAGER_DN" -w 'MANAGER_PASSWORD' -H ldaps://1.2.3.4 -x -b "DC=USERS,OU=Y,O=io" "(UID=USERNAME)"

Without a userSearchBase

//Search using manager DN, manager password on url with base of "X"
# When: userSearchFilter=(uid={0}) 
ldapsearch -D "MANAGER_DN" -w 'MANAGER_PASSWORD' -H ldaps://1.2.3.4 -x   "(UID=USERNAME})"

Without a userSearchFilter

//Search using manager DN, manager password on url with base of "X"
# When: --user-dn-pattern=(uid={0},ou=users) 
ldapsearch -D "MANAGER_DN" -w 'MANAGER_PASSWORD' -H ldaps://1.2.3.4/OU=Y,O=io -x "(CN=USERNAME,OU=users,OU=Y,O=IO))"

Configuration

Add the parameters to gate-local.yml and set as appropriate. More information can be found below on how these parameters impact LDAP auth.

ldap:
  enabled: true
  url: ldaps://host/a/b/c
  managerDn: dn=bob
  managerPassword: encrypted:some:password
  groupSearchBase: groupInfo
  userDnPattern: <optional> userDnPattern
  userSearchBase: <optional> searchBase
  userSearchFilter: <optional> searchFilter

The source code for the ldap configuration in gate can show you how this is utilized.

Optional configurations

You can also use userSearchBase (optional) and userSearchFilterr if the simpler userDnPatternn does not match what your organization uses for userDn. We don’t explore this use case here, but you can read up more on LDAP search filters here .

Active Directory

We recommend NOT using the userDnPattern argument for AD. The following issue has been reported in an issue ticket:

userDnPattern should remain unset - AD groups store user DNs in the memberOf attribute; finding DNs from sAMAccountNames is easily doable but not with a simple, single-level pattern. The DN contains the CN, and that can’t really be constructed without sub searches. userSearchFilter takes precedence if there’s no user-dn-pattern set.

Here’s the raw settings to add to gate-local.yml for active direct as an example:

ldap:
  enabled: true
  url:  ldaps://somethingsomething:686/ou=users,ou=company,o=com
  userSearchFilter: (&(objectClass=user)(sAMAccountName={0}))
  managerDn: CN=SVC_LDAP_USER_RO,OU=service-users,OU=company,O=com
  managerPassword: super-secret-password

The managerUser will then find a user in your ou=users,ou=company,o=com directory via a subtree search. You should be able to set the user-search-base parameter vs. including it on the URL to have it specified separately.

Next steps

Now that you’ve authenticated the user, proceed to setting up their authorization .

Troubleshooting

Review the general authentication workflow .
Use an Incognito window . Close all Incognito windows between attempts.
I’m getting the “Bad Credentials” exception mentioned above, but my username and password is correct!

Ensure that the fully qualified user DN is correct. Confirm with your LDAP administrator how your organization’s LDAP directory is structured.

Docs: OAuth 2.0

Mon, 01 Jan 0001 00:00:00 +0000

OAuth 2.0 is the preferred way to authenticate and authorize third parties access to your data guarded by the identity provider. To confirm your identity, Spinnaker requests access to your email address from your identity provider. Please read ALL of the documentation on this page as just setting the provider may not work for your environment.

Configuration

Spinnaker has moved to spring security standard DSL for configuration oauth2. You can find these configuration parameters in the spring documentation around client registry properties. The following needs to be set in your gate-local.yml configuration file according to the expected configuration for your provider. An example using Google:

spring:
  security:
    oauth2:
      client:
        registration:
          userInfoMapping:
            email: email
            firstName: given_name
            lastName: family_name
          userInfoRequirements:
            hd: <domain>
          google:
            client-secret: <client-secret>
            scope: profile,email
            client-id: <client-id>
            redirect-uri: https://<your-domain>/login/oauth2/code/<providerid-aka-google>
        provider:
          google:
            user-info-uri: https://www.googleapis.com/oauth2/v3/userinfo
            authorization-uri: https://accounts.google.com/o/oauth2/v2/auth
            token-uri: https://www.googleapis.com/oauth2/v4/token

Note that userInfoRequirements is a spinnaker specific implementation. See information below on configuration user info requirements

OAuth 2.0 providers

Consult the documentation of your OAuth 2 provider to determine the appropriate values to put in each configurable field. For some common OAuth 2.0 providers, specific documentation is provided here.

If you’re using one of these providers, please follow the appropriate link below for specific instructions on configuring your provider:

Network architecture and SSL termination

During the OAuth workflow , Gate makes an intelligent guess on how to assemble a URI to itself, called the redirect URI. Sometimes this guess is wrong when Spinnaker is deployed in concert with other networking components, such as an SSL-terminating load balancer.

You can manually set the redirect URI at the spring.security.oauth2.client.registration.<provider>.redirect-uri parameter as documented above.

Old spinnaker versions

Though no longer supported, for Spinnaker below v2025.2.0 configuration would be set in gate-local.yml similar to:

security:
  authn:
    oauth2:
      client:
        preEstablishedRedirectUri: https://my-real-gate-address.com:8084/login

Be sure to include the /login suffix at the end of the of your preEstablishedRedirectUri!.

Additionally, some configurations make it necessary to “unwind” external proxy instances. This makes the request to Gate look like the original request to the outer-most proxy. Add this to your gate-local.yml file.

server:
  tomcat:
    protocolHeader: X-Forwarded-Proto
    remoteIpHeader: X-Forwarded-For
    internalProxies: .*

UserInfoMapping

The userInfoMapping field in the configuration is used to map the names of fields from the userInfoUri request to Spinnaker-specific fields. For example, if your user profile in your OAuth 2.0 provider’s system looks like:

{
  "user": "fmercury",
  "mail": "fmercury@queen.com",
  "fName": "Freddie",
  "lName": "Mercury"
}

Then your userInfoMapping should look like:

userInfoMapping:
  email: mail
  firstName: fName
  lastName: lName
  username: user

Restricting access based on User Info

User access can be restricted further based on the user info from an OAuth ID token. This requirement is set via the userInfoRequirements property. THis is a map of key/value pairs. The values are interpreted as regular expressions if they start and end with ‘/’. This enables restricting login to users from a specific domain or having a specific attribute.

For example:

security:
  authn:
    oauth2:
      userInfoRequirements:
        hd: your-org.net
        batz: /^Sample.*Regex/
        foo: bar

Next steps

Now that you’ve authenticated the user, proceed to setting up their authorization .

Troubleshooting

Review the general authentication workflow .
Use an incognito window .
I’m getting an Error: redirect_uri_mismatch from my OAuth provider.

The full error may look something like:

Error: redirect_uri_mismatch. The redirect URI in the request, https://some.url/login , does not match the ones authorized for the OAuth client.

This likely means you’ve not set up your OAuth credentials correctly. Ensure that the Authorized Request URIs list contains https://my-gate-address/login/oauth2/code/<provider> (no trailing /). provider should be one among azure,github,google,oracle,other For Spinnaker below v2025.2.0, it should be https://my-gate-address/login

Docs: SAML 2.0

Mon, 01 Jan 0001 00:00:00 +0000

Security Assertion Markup Language (SAML) is an XML based way to implement single sign-on (SSO).

A cryptographically signed XML document (known as a “SAML Assertion”) is sent to the API gateway server (Gate) with your identifying information, such as username and group membership.

Gate verifies the XML document’s signature using a metadata file, and if successful, it associates the identifying information with the user and allows the user to proceed as authenticated.

Identity provider setup

In your SAML Identity Provider (IdP), download the metadata.xml file. Some providers expose this as a URL which can be used directly vs needing to download, as long as spinnaker gate can access the URL. It may look something like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<md:EntityDescriptor 
    xmlns:md="urn:oasis:names:tc:SAML:2.0:metadata"    
    entityID="https://accounts.google.com/o/saml2?idpid=SomeValueHere" 
    validUntil="2021-05-16T15:17:27.000Z">
  <md:IDPSSODescriptor 
      WantAuthnRequestsSigned="false" 
      protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:X509Data>
          <ds:X509Certificate>
MIIDdDCCAlygAwIBAgIGAVS/Sw5yMA0GCSqGSIb3DQEBCwUAMHsxFDASBgNVBAoTC0dvb2dsZSBJ
bmMuMRYwFAYDVQQHEw1Nb3VudGFpbiBWaWV3MQ8wDQYDVQQDEwZHb29nbGUxGDAWBgNVBAsTD0dv
b2dsZSBGb3IgV29yazELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWEwHhcNMTYwNTE3
MTUxNzI3WhcNMjEwNTE2MTUxNzI3WjB7MRQwEgYDVQQKEwtHb29nbGUgSW5jLjEWMBQGA1UEBxMN
TW91bnRhaW4gVmlldzEPMA0GA1UEAxMGR29vZ2xlMRgwFgYDVQQLEw9Hb29nbGUgRm9yIFdvcmsx
CzAJBgNVBAYTblVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMIIBIjANBgkqhkiG9w0BAQEF46OCAQ8A
MIIBCgKCAQEA4JsnpS0ZBzb7DtlU7Zop7l+Kgr7NzusKWcEC6MOsFa4Dlt7jxv4ScKZ/61M5WKxd
5YX0ol1rPokpNztj+Zk7OXrG8lDic0DpeDutc9pcq0+9/NYFF7WR7TDjh4B7Txnq7SerSB78fT8d
4rK7Bd+cu/cBIyAAyZ5tLeLbmTnHAk093Y9vF3mdWQnfAhx4ldOfstF6G/d2ev7I5xjSKzQuH6Ew
3bb3HLcM4uEVevOfNAlh1KoV4vQr+qzbc9UEFcPRwzuTwGa6QjfspWW7NgXKbHHC+X6a+gqJrke/
6l2VvHaQBJ7oIyt4PCdel2cnUkvuxvzHPYedh1AgrIiSP1brSQIDAQABMA0GCSqGSI34DQEBCwUA
A4IBAQCPqMAIau+pRDs2NZG1nGfyEMDfs0qop6FBa/wTNis75tLvay9MUlxXkTxm9aVxgggjEyc6
XtDjpV0onrH0jBnSc+vRI1GFQ48EO3owy3uBIeR1aMy13ZwAA+KVizeoOrXBJbvIUZHo0yfKRzIu
gtM58j58BdAFeYo+X9ds/ysvZ8FIGTLqMl/A3oO/yBNDjXR9Izoqgm7RX0JJXGL9Y1AgmEjxyqo9
MhxZAGxOHm9HZWWfVMcoe8p62mRJ2zf4lkNPBnDHrQ8MDPSsXewAuiSnRBDLxhdBgyThT/KW7Q06
rGa6Dp0rntKWzZE3hGQS0AdsnuFY/OXbmkNG9WUrUg5x
          </ds:X509Certificate>
        </ds:X509Data>
      </ds:KeyInfo>
    </md:KeyDescriptor>
    <md:NameIDFormat>urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress</md:NameIDFormat>
    <md:SingleSignOnService 
        Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" 
        Location="https://accounts.google.com/o/saml2/idp?idpid=SomeValueHere"/>
    <md:SingleSignOnService 
        Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" 
        Location="https://accounts.google.com/o/saml2/idp?idpid=SomeValueHere"/>
  </md:IDPSSODescriptor>
</md:EntityDescriptor>

Create a Spinnaker SAML application.
Specify the login URL as https://localhost:8084/saml/SSO. Replace “localhost” with Gate’s address, if known.
Specify a unique entity ID (we’ll use spinnaker.test in our example).
Enable the users you’d like to have access to your Spinnaker instance.

Generate a keystore and key in a new Java Keystore with some password:

keytool -genkey -v -keystore saml.jks -alias saml -keyalg RSA -keysize 2048 -validity 10000

Configure gate

Starting with Spinnaker 2025.x.x, a new SAML integration mechanism has been introduced to improve compatibility, simplify configuration, and align with modern identity provider (IdP) standards. This replaces some of the legacy configuration and libraries used in earlier versions of Spinnaker.

The below approach applies to certain IDPs that support signing credentials (Okta is NOT one of these). This is a required change for keycloak and a few other providers. Note alternatively to using a custom volume map, you can use encryptedFile secret store references.

create configMap

kubectl create configmap configmap-saml --from-file=saml.jks --from-file=<your_metadata>.xml --from-file=<your_cert>.pem --from-file=<your_priv>.pem

Configure gate by adding to gate-local.yml

saml:
  enabled: true
  issuerId: <Client>
  ## Can be something LIKE https://integrator-3395767.okta.com/app/exku1rxeyhJeP16iJ697/sso/saml/metadata
  ## as an alternative to a local file copy.  Gate will then refresh on a 15 minute interval this file and
  ## at startup 
  metadataUrl: file:/opt/spinnaker/saml/<your_cert>.xml
  keyStore: file:/opt/spinnaker/saml/saml.jks
  keyStorePassword: <optional> from jks creation
  keyStoreAliasName: <optional> defaults to "mykey" when using keytool
  keyStoreType: jks (PKCS12 is new and should be used instead)
  sign-requests: true
  signing-credentials:
  - certificate-location: file:/opt/spinnaker/saml/<your_cert>.pem
    private-key-location: file:/opt/spinnaker/saml/<your_priv>.pem

Network architecture and SSL termination

Please check on the SSL Documentation for more information.

Workflow

The SAML workflow below reflects the process when the user navigates to Spinnaker first, is redirected to the SAML IdP for login, and redirected back to Spinnaker. Some SAML providers will allow the user login to the SAML provider first, and click a link to be taken to Spinnaker.

sequenceDiagram participant Deck participant Gate participant IdentityProvider Deck->>+Gate: GET /auth/user and if blank redirect to auth URL Deck->>+Gate: GET /auth/redirect?redirect_uri=fromOriginalDeckUrl Gate->>-IdentityProvider: JavaScript to redirect to https://idp.url/?SAMLRequest=... IdentityProvider->>User: Login User->>IdentityProvider: Complete login IdentityProvider->>+Gate: POST /saml/SSO Gate->>+Deck: HTTP 302 to originalDeckUrl

User attempts to access a protected resource by using Spinnaker. Deck detects an empty session user and initiates the login flow
Gate redirects to the SAML provider, passing a few query params:
- SAMLRequest: a Gzip’ed XML authentication request.
- SigAlg: The algorithm used to generate the Signature parameter.
- Signature: A digest of the SAMLRequest using the SigAlg algorithm and the server’s key.

IDP initiated flow

This is when a user logins in from their identity provider negating the need for gate to send a redirect.


  
        sequenceDiagram
        
        participant Deck
        participant Gate
        participant IdentityProvider
        
        User->>+IdentityProvider: User sends credentials
        IdentityProvider->>-Gate: POST /saml/SSO with { SAMLResponse: ... }
        Gate->>-Deck: HTTP 302
        Note right of Gate: User identity verified
        Note right of Gate: Gate extracts data based on userInfoMapping
        Gate->>-Deck: HTTP 302 /something/protected

User logs into their provider and clicks a login button
A SAML response must be POSTed to /saml/SSO, and most browsers won’t re-POST when given an HTTP 302. Instead, providers sometimes return a page (with HTTP 200) that has a self-submitting HTML form to POST to Gate’s /saml/SSO endpoint.
Gate verifies the message’s integrity by checking its signature, and thus verifying the user’s identity information.
Gate determines the username and/or email address, and optionally extracts group membership (if sent by the IdP).
With the user’s identity verified, Gate redirects the user to the originally requested URL.

Next steps

Now that you’ve authenticated the user, proceed to setting up their authorization .

Troubleshooting

Review the general authentication guide .
Review the authentication reference guide .
Use an incognito window .

Docs: X.509 Client Certificates

Mon, 01 Jan 0001 00:00:00 +0000

X.509 client certificates utilize public-key infrastructure (PKI) in order to authenticate clients. X.509 can be used simultaneously with one of the other authentication methods or by itself. Users commonly generate a certificate for their non-UI or script based clients, as this is generally easier than dynamically obtaining an OAuth Bearer token or SAML assertion.

Certificates

If you followed the SSL guide, you may already have generated a certificate authority (CA). Using this CA, we can generate a client certificate using openssl.

Create the client key. Keep this file safe!

openssl genrsa -des3 -out client.key 4096

Generate a certificate signing request for the server. Ensure the Common Name is set to a non-empty value.
```
openssl req -new -key client.key -out client.csr
```

Use the CA to sign the server’s request. If using an external CA, they will do this for you.

openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt

(Optional) Format the client certificate into browser importable form.

openssl pkcs12 -export -clcerts -in client.crt -inkey client.key -out client.p12

Encoding role information in x509 extensions

The certificates generated here only allow for the authentication of a user’s identity, not user roles. If using Fiat, these certificates are not sufficient for authorization.

roleOid is used for this example.

Client certificates with role information are parsed when roleOid is provided. This OID is configurable and is set in your gate-local.yml file. The OID provided in the example below is defined here .

Encoding with any other OID can be done by editing the openssl.conf.

Creating an x509 client certificate with user role information

Create a new Openssl config file openssl.conf with the following contents:

[ req ]
#default_bits		= 2048
#default_md		= sha256
#default_keyfile 	= privkey.pem
distinguished_name	= req_distinguished_name
attributes		= req_attributes
req_extensions = v3_req

[ req_distinguished_name ]
countryName			= Country Name (2 letter code)
countryName_min			= 2
countryName_max			= 2
stateOrProvinceName		= State or Province Name (full name)
localityName			= Locality Name (eg, city)
0.organizationName		= Organization Name (eg, company)
organizationalUnitName		= Organizational Unit Name (eg, section)
commonName			= Common Name (eg, fully qualified host name)
commonName_max			= 64
emailAddress			= Email Address
emailAddress_max		= 64

[ req_attributes ]
challengePassword		= A challenge password
challengePassword_min		= 4
challengePassword_max		= 20

[ v3_req ]
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
1.2.840.10070.8.1 = ASN1:UTF8String:spinnaker-example0\nspinnaker-example1

The final line in this file 1.2.840.10070.8.1= ASN1:UTF8String:spinnaker-example0\nspinnaker-example1 is what matters for creating a client certificate with user role information, as anything after UTF8String: is encoded inside of the x509 certificate under the given OID.

Where:

1.2.840.10070.8.1 - OID
spinnaker-example0\nspinnaker-example1 - Spinnaker user groups

Note: If providing multiple groups, as in this example, separate them with a new line (\n). The new line \n shows as a %0A in the certificate.

Generate a CSR for a new x509 certificate and the given openssl.conf:

openssl req -nodes -newkey rsa:2048 -keyout key.out -out client.csr \
    -subj "/C=US/ST=CA/L=Oakland/O=Spinnaker/CN=example@example.com" -config openssl.conf

Create extention config file extension.conf to apply roles when signing the server requests.
```
[ v3_req ]
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
1.2.840.10070.8.1 = ASN1:UTF8String:spinnaker-example0\nspinnaker-example1
```
The same rule for the roles definition applied to this section, as it’s explained in the first step of this section.

Use the CA to sign the server’s request. (If using an external CA, they do this for you.)

openssl x509 -req -days 365 -in client.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out client.crt -extensions v3_req  -extfile ./extension.conf

Issuing the client certificate using AWS Certificate Manager

If you are using AWS Certificate Manager’s Private Certificate Authority to issue client certificates containing role information, you will need to provide a certificate template that allows passthrough of these extensions from the Certificate Signing Request. BlankEndEntityCertificate_CSRPassthrough/V1 is one such template. To issue the certificate using ACM Private CA, first generate the CSR following steps 1 and 2 above. Then, run the following to issue the certificate:

aws acm-pca issue-certificate --csr fileb://client.csr \
    --template-arn arn:aws:acm-pca:::template/BlankEndEntityCertificate_CSRPassthrough/V1 \
    --certificate-authority-arn [private CA ARN] \
    --signing-algorithm SHA256WITHRSA \
    --validity Value=365,Type="DAYS"

You can then fetch the issued client certificate and output it into a file with:

aws acm-pca get-certificate --certificate-authority-arn [private CA ARN] \
    --certificate-arn [ARN of previously generated certificate] \
    --query Certificate \
    --output text > client.crt

Configure Spinnaker

Add the following to your gate-local.yml

x509:
  enabled: true
  #regix: if you want to use the "Email Address" field from the certificate, the regex would be: EMAILADDRESS=(.*?)(?:,|$)
  subject-principal-regex:  <Optional > regex
  role-oid: 1.2.840.10070.8.1
  required-roles: 
  - admin
  - some-random-group
  ## HIGHLY recommend setting this as it reduces the fiat login operations by only logging in every 5 minutes
  ## instead of on EVERY x509 call
  loginDebounce:
     enabled: true
     ## Defaults to 5 minutes
     debounceWindowSeconds: 300
 
## Required if you want SSL as a required option
server:
  ssl:
    enabled: true
    
## This sets up a dedicated API port for MTLS that NEEDS x509 auth.  Used with an NLB
## or LB service to expose gate directly and REQUIRE x509 auth.  
## this requires ALSO that ssl be enabled.  WITHOUT this, the user may be prompted
## for a (optional) certificate to login with instead of any other login configuration. The x509 cert
## in those cases is a "WANT" which is what would prompt the user for a cert.  
default:
  apiPort: 8085

API port

By enabling X.509 on the main 8084 port, it causes the browser to ask the user to present their client certificate. Many end-users can get confused or annoyed by this message, so it is preferable to move this off of the main port.

You can move the client certificate-enabled port by setting default.apiPort value to something other than 8084. This enables an additional port configuration that is hardcoded to need a valid X.509 certificate before allowing the request to proceed.

Workflow

Unlike the other authentication methods, X.509 does not have any redirects or fancy control passing between Deck, Gate, and a third-party identity provider. Connections are either established with a valid certificate or they’re not.

Next steps

Now that you’ve authenticated the user, proceed to setting up their authorization .

Troubleshooting

Review the general authentication guide .
Review the authentication reference guide .
Use an incognito window .

Spinnaker – Authentication

Docs: LDAP

Notes

How to determine the “User DN”

Testing with ldapsearch

Configuration

Optional configurations

Active Directory

Next steps

Troubleshooting

Docs: OAuth 2.0

Configuration

OAuth 2.0 providers

Network architecture and SSL termination

Old spinnaker versions

UserInfoMapping

Restricting access based on User Info

Next steps

Troubleshooting

Docs: SAML 2.0

Identity provider setup

Configure gate

Network architecture and SSL termination

Workflow

Service-Provider login flow

IDP initiated flow

Next steps

Troubleshooting

Docs: X.509 Client Certificates

Certificates

Encoding role information in x509 extensions

Creating an x509 client certificate with user role information

Issuing the client certificate using AWS Certificate Manager

Configure Spinnaker

API port

Workflow

Next steps

Troubleshooting