Setting up Authorization with Google Groups


#1

The documentation here (https://www.spinnaker.io/setup/security/authorization/) could really use some updates to explain more about how authorization works. First of all, I have read in many places that the requiredGroupMemberships property is deprecated (i’ve even heard that it straight up doesn’t work in Spinnaker 1.7.5+). Despite this, I’ve seen some really weird behavior while trying to figure out how exactly Authorization should work.

I am able to see Google Groups that I belong to in the “Edit Application Properties>Permissions” dropdown which to me indicates that the service account that has the GSuite Group Read access appears to be working.

  1. There is no information I can find that explains how these groups should be specified when using Google OAuth and trying to specify Google Groups… My guess is that they should look exactly like the names in the Permissions dropdown… but that doesn’t seem to work. I’ve also tried including the domain but have not had luck finding the solution here…

For example: I added READ and WRITE permissions for our “dev” group to our account (cluster-- using k8s v2) and the application ceases to exist in the UI when this is done.

  1. My application exists across multiple accounts (which according to the documentation above is fine), but when enabling permissions on one account… the entire application becomes completely inaccessible even for the “accounts” that don’t have any permissions enabled… not exactly sure how this should work.

  2. I currently have our authorization disabled (due to the issues called out above) but didn’t remove the “permissions” I had defined on our account. Even with authorization disabled I still get the following message when trying to trigger our pipeline for this account:

Exception ( Deploy Manifest )
my@email.com is not authorized (account: my-authorized-spinnaker-account, description: KubernetesDeployManifestDescription)

the same thing happens when this is triggered via our pubsub trigger but with “anonymous” instead of "my@email.com".

It is possible that I just don’t understand enough about how to configure Fiat, but some of these items seem quite strange to me and have made enabling authorization somewhat of a headache, especially in an environment where we are now actively using our spinnaker instance for our day to day development work. Any help would be greatly appreciated!


#2

@Stephen_Chen is cleaning up the requiredGroupMembership -> permissions object and can comment.

Yeah, security is something we’ve struggled to really clean up, but every feedback helps. There’s enough at play here, where perhaps it’s worth @ezimanyi or myself doing a working session together with you, either via slack or even a Hangouts to work through this? Please reach out to me with what works for you.


#3

@stevenkim that would be great. I am available on either Hangouts or Slack. I do idle in the Spinnaker slack if that’s easier. My username should be @banderson, otherwise my hangouts is just my username on the forums @gmail.com.


#4

Yeah, the docs have been somewhat out of date since the addition of Permissions a while back. I am currently working on adding permissions support in halyard and updating the docs to encourage people to move to it. There’s also been some posts mentioning that requiredGroupMembership is no longer working, although I tried reproducing it this morning and my config does restrict access properly, so not sure is the actual state of that yet.

If it helps, here is the docs update PR I have currently: https://github.com/spinnaker/spinnaker.github.io/pull/813 which will go in after halyard releases with the new commands https://github.com/spinnaker/halyard/pull/954. For now, you can add the permissions in your clouddriver-local.yml, or halyard with requiredGroupMembership.


#5

We upgraded spinnaker to 1.9.2 on GCE in order to avoid possible breaking changes that were highlighted earlier. Somehow Fiat is not working properly in this version. We have enabled google group permissions in clouddriver along with requiredmembership and we are using google groups under fiat authorisation. But somehow its very flaky in this version. Sometime it works and most of the time it doesn’t. Its allowing anonymous user to delete components even when we are logged-in as valid gmail user it still gets anonymous from nowhere. We are using IAP authentication on Gate and currently everything is setup on GCE. The READ and WRITE permissions doesn’t seems to work. Let me know if you need logs for this issue, we are not able to upgrade our production spinnaker setup due to this potential security risk.


#6

Hi, what is your authentication config on gate? It seems like the users are not being signed in properly - anonymous user should not be involved here.


#7

@Stephen_Chen
gate config

spectator:
  applicationName: ${spring.application.name}
  webEndpoint:
    enabled: false

server:
  ssl:
    enabled: false
  port: '8084'
  address: 0.0.0.0
security:
  basic:
    enabled: true
  user: {}
cors: {}
google:
  iap:
    enabled: true
    audience: /projects/xxxxxxx/global/backendServices/yyyyyyyy

# halconfig

redis:
  connection: ${services.redis.baseUrl:redis://localhost:6379}

#8

So to give context spinnaker is fronted by GCP global HTTPS LB with IAP enabled. And we are using IAP auth in Gate. To me it looks like some how IAP authtoken for given user is not maintained properly. I tried cleaning the creds and cookies from my browser and even tried using Incognito and tried using logout and login again but some how something is going wrong.

After sometime the READ and WRITE starts taking effect but I make some changes in Clouddriver permissions and restart clouddriver service try and go to UI and perform some action some how changes don’t take effect.

I can see logs related to clouddriver making request to fiat but i cannot see any logs in fiat for that particular call made to it via clouddriver

Aug 31 11:17:30 clouddriver-halyard clouddriver[21930]: 2018-08-31 11:17:30.971  INFO 21930 --- [0.0-7002-exec-1] c.n.spinnaker.fiat.shared.FiatService    : ---> HTTP GET http://fiat-ip:7003/authorize/sweetibr%40gmail.com
Aug 31 11:17:30 clouddriver-halyard clouddriver[21930]: 2018-08-31 11:17:30.976  INFO 21930 --- [0.0-7002-exec-1] c.n.spinnaker.fiat.shared.FiatService    : <--- HTTP 200 http://fiat-ip:7003/authorize/sweetib%40gmail.com (5ms)
Aug 31 11:17:34 clouddriver-halyard clouddriver[21930]: 2018-08-31 11:17:34.697  INFO 21930 --- [0.0-7002-exec-4] c.n.spinnaker.fiat.shared.FiatService    : ---> HTTP GET http://fiat-ip:7003/authorize/anonymous
Aug 31 11:17:34 clouddriver-halyard clouddriver[21930]: 2018-08-31 11:17:34.702  INFO 21930 --- [0.0-7002-exec-4] c.n.spinnaker.fiat.shared.FiatService    : <--- HTTP 200 http://fiat-ip:7003/authorize/anonymous (4ms)

why there are two types of log at same moment? and no logs in fiat for this get request doesn’t make sense to me


Warning! Breaking Change in GCE API
#9

This authorization issue is IAP specific - Our session management probably has some bug. FWIW I made some changes on the module yesterday, which should change the behavior of this and fix some other issues. https://github.com/spinnaker/gate/pull/591. It’ll be out in 1.9.3

Please file a github issue on me, I will test this out with authz more - you’re the first user I know of trying this out already :stuck_out_tongue:


#10

We were trying to implement some complicated use case hence ended up using IAP(as suggested by @ezimanyi ) instead of google oauth. We switched the authentication from google oauth to IAP last week only and since than we are facing bit of issues. UI doesn’t reflect things properly may be due to this potential bug when it uses anonymous user as login from nowhere. This issue is not obvious in small setup but its bit painful in the bigger setup to manage. When is 1.9.3 supposed to be released @Stephen_Chen ? Our production is using 1.8.4 with IAP we might have to rollback it back to google oauth if its same issue in that version(we haven’t received any issues yet there, but i have noticed flaky UI while rendering pipelines and clusters).


#11

There are so many bugs we are already hopping between one version to another :sob:. Its giving us tough time to manage it. If its something that is going to take time let us know we will go back to using google oauth with 1.9.2


#12

Let’s chat on slack about the other issues - 1.9.3 will probably be there in a few weeks. Would like to know more about your use case as well.