Enabling pipeline permissions


#1

How do we configure orca/deck using halyard for k8s deployments?



#2

#3

While we do not have halyard support for enabling pipeline permissions yet, you should be able to use the instructions here for now: https://www.spinnaker.io/setup/security/authorization/pipeline-permissions/#enabling-pipeline-permissions


#4

I have a Fiat Service Account related question. While it does not directly pertain to the core discussion in this thread, since Pipeline permissions are enabled using Service Accounts behind the scenes, I thought I would ask here.

We have a Spinnaker setup that authenticates and authorizes using LDAP (Microsoft AD). I have noticed that every time I create a Fiat Service Account (say, abc), if that Fiat Service Account is not an existing LDAP user, the Fiat “sync” API call fails. I am not sure what the sync API call is doing.

Question: Are Fiat Service Accounts arbitrary names stored by Spinnaker used only for creating a single reference to a collection of LDAP Groups? Or are they supposed to be actual LDAP CN entries, just like human users?


#5

Fiat service accounts are not actual entries in your LDAP. The service account and the collection of groups it references is stored in Front50 and is then cached in Redis with periodic syncs.

Ideally, we should not be querying LDAP with the service accounts during a sync. Currently, however, we do try to fetch roles for a service account during a sync and it logs an error message. This error message can be ignored. The service account roles should still be properly synced from Front50 even though we make an extraneous call to LDAP.

Is the error you are talking about this log message or are you seeing a different error?


#6

Thanks for the quick reply and validating a few assumptions that we had as well. As a matter of fact, this very afternoon after wading through Fiat codebase, we realized how Fiat was using Redis to store the “account”, “application” and “service account” permissions for each user (actual LDAP user as well as Service Account).

Yes, we do think there is a bug in here somewhere that is causing the Fiat functionality to break for us, including the newly launched Pipeline Permissions feature.

Here’s how you can duplicate it. I am sure it will work with other Group Providers as well, but I have only tested this where the Group Provider is LDAP Groups:

I create a service account using the following command:

curl -X POST \
  -H "Content-type: application/json" \
  -d '{ "name": "testsa@managed-service-account", "memberOf": ["code-phwhitin"] }' \
  $FRONT50/serviceAccounts | jq .

It successfully creates the service account, as this API call confirms it:

curl -s $FRONT50/serviceAccounts | jq .

Now, code-phwhitin is an LDAP group with just one LDAP user (phwhitin). Before creating this service account, this user did not have access to any Fiat Service Account.

Since I am not sure if the sync command is mandatory after creating a new service account, I decided to run this command to see if the new service account testsa@managed-service-account got added to the user phwhitin:

curl -s $FIAT/authorize/phwhitin | jq .

Turned out, it did not. So, I dutifully run the sync command:

curl -X POST $FIAT/roles/sync

This command fails with this error:

{
  "timestamp" : 1538008639775,
  "status" : 500,
  "error" : "Internal Server Error",
  "exception" : "java.lang.NullPointerException",
  "message" : "No message available"
}

I see the following errors in Fiat log. I have only shown a snippet of it.

spin-fiat-6b96d6447f-8vfx7 fiat 2018-09-27 00:37:19.725  INFO 1 --- [0.0-7003-exec-6] c.n.s.fiat.controllers.RolesController   : [] Full role sync invoked by web request.
spin-fiat-6b96d6447f-8vfx7 fiat 2018-09-27 00:37:19.743  INFO 1 --- [0.0-7003-exec-6] c.n.s.fiat.roles.UserRolesSyncer         : [] Synced anonymous user role.
spin-fiat-6b96d6447f-8vfx7 fiat 2018-09-27 00:37:19.774 ERROR 1 --- [0.0-7003-exec-6] c.n.s.f.r.ldap.LdapUserRolesProvider     : [] Unable to find a single user entry
spin-fiat-6b96d6447f-8vfx7 fiat org.springframework.dao.IncorrectResultSizeDataAccessException: Incorrect result size: expected 1, actual 0
spin-fiat-6b96d6447f-8vfx7 fiat 	at org.springframework.security.ldap.SpringSecurityLdapTemplate.searchForSingleEntryInternal(SpringSecurityLdapTemplate.java:361)
spin-fiat-6b96d6447f-8vfx7 fiat 	at org.springframework.security.ldap.SpringSecurityLdapTemplate$3.executeWithContext(SpringSecurityLdapTemplate.java:318)
spin-fiat-6b96d6447f-8vfx7 fiat 	at org.springframework.ldap.core.LdapTemplate.executeWithContext(LdapTemplate.java:817)
...

You can see the full error log here

I was hoping this error would be benign and that upon running the API, the service account testsa@managed-service-account added to phwhitin

curl -s $FIAT/authorize/phwhitin | jq .

it did not. :frowning_face:

Here’s a little caveat: if the service account name actually matches an actual LDAP user in our LDAP server, the sync API call works like a charm. And therein lies our problem. We really do not want to find ourselves being forced to create an LDAP user for every single Fiat Service account we create.

Any ideas if this NPE issue is truly a bug. Also, any ideas how we can bypass this without creating an actual LDAP user.

Thanks in advance!


#7

Thanks for the writeup @indrayam. Very helpful. I haven’t seen the NPE before and this definitely looks like a bug. I saw you filed https://github.com/spinnaker/spinnaker/issues/3388. I’ll look into it and update the Github issue.


#8

Thanks, @dibyom! Please feel free to let me know if there is anything I can do to help.