Add ServiceAccountName support to operator #283
Conversation
|
Sorry for the late reply. It seems your code generator is old and it regenerated some files, that's why the tests fail. I think @asymmetric and @krnowak had some ongoing discussions on where in the struct to put new fields. They're off until Monday, maybe we can sync about this then. |
|
I think you ran the code-generator at a version that's either too new or too old. Could you check out the Also, could you explain a usecase for this? AFAIU, you don't need to care about Is this related to the work on the builder? |
|
Ah I think I have an old version of the code generator.
I was trying to run the habitat-updater service inside GKE last week and
realized I couldn't because of rbac. After fiddling with it for a bit I saw
that is getting the default service account but it right have the right
priceless and I didn't want to grant it extra permissions.
…On Mon, May 28, 2018, 5:27 AM Lorenzo Manacorda ***@***.***> wrote:
I think you ran the code-generator at a version that's either too new or
too old. Could you check out the kubernetes-1.10.0 tag on the
code-genearator and run it again?
Also, could you explain a usecase for this? AFAIU, you don't need to care
about ServiceAccounts for your Pods, unless the stuff running in them
needs to talk to the APIServer, as they would default to the default SA.
Is this related to the work on the builder?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#283 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABE_bfWYbCcElwLVEVxmKk2RR3u8uXC0ks5t29EKgaJpZM4UDzTS>
.
|
|
I guess the problem with running the operator on GKE with RBAC enabled is that we cannot create I'm not sure we need support for custom |
|
I think both are true. An admin will need to create the role but we should
be able to tell a service what that role is, which is the goal of this pr.
Even the operator needs to know what it's service role is in its deployment
yaml
…On Mon, May 28, 2018, 6:31 AM Lorenzo Manacorda ***@***.***> wrote:
I guess the problem with running the operator on GKE with RBAC enabled is
that we cannot create ClusterRoles. This should be fixed IMO by the
person in charge of user authorizations.
I'm not sure we need support for custom ServiceAccounts once that's taken
care of. WDYT?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#283 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABE_bcdxts1DX74c-2NcM4JA5keWLrL7ks5t2-ACgaJpZM4UDzTS>
.
|
|
I think two things are being conflated here. The operator needs its own SA (because it needs to do special tihngs with the API), and that's taken care of by
Do we though? Are there usecases where a service running in a
Sure, but that doesn't require changes to the |
|
I this particular case, the service running inside the pod needs to talk to
the kubernetes API. See https://github.com/habitat-sh/habitat-updater
The updater is modifying the Habitat resource to update the image. When
this is run in an rbac env it barfs because that pod doesn't have
permission to patch resources, list other pods, etc
…On Mon, May 28, 2018, 9:10 AM Lorenzo Manacorda ***@***.***> wrote:
I think two things are being conflated here. The operator needs its own SA
(because it needs to do special tihngs with the API), and that's taken care
of by examples/rbac/rbac.yml.
Pods on the other hand most likely won't need to talk to the API, so they
can just keep on using the default SA.
we should be able to tell a service what that role is
Do we though? Are there usecases where a service running in a Pod has
needed to talk to the API server?
Even the operator needs to know what it's service role is in its
deployment yaml
Sure, but that doesn't require changes to the Habitat type.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#283 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABE_bfm8BPvNRXjzIJnSf9y1cZBkFZjXks5t3AVqgaJpZM4UDzTS>
.
|
|
@elliott-davis could you re-run the code-gen with the right tag? The other missing thing would be an example using this key. After that, I think we should be good to go :) |
elliott-davis
force-pushed
the
elliott/service_account
branch
2 times, most recently
from
e82f463
to
5564407
Compare
elliott-davis
changed the title
|
@iaguis What was the usecase you mentioned where it would make sense to add the SA field? |
|
If you have some application running in your cluster that's protected by RBAC and you want to access it from a service deployed with the Habitat Operator, you will need a Service Account that gives access to the RBAC-protected application. For example, if you want a service that deploys Helm Charts, you probably need to pass the |
Although this means the application needs to be accessible through some kind of k8s API so maybe it's not the use case you're looking for... |
|
Yeah my use-case is creating a service account for my service to interact with RBAC protected services in a cluster. |
jamesc
force-pushed
the
elliott/service_account
branch
2 times, most recently
from
5382424
to
32d4bfe
Compare
When running services under the operator that need a service account it is impossible to specify one given the current service definition. This is useful for services running in pods that need to communicate with the kubernetes API with RBAC mode enabled Signed-off-by: Elliott Davis <elliott@excellent.io> Signed-off-by: James Casey <james@chef.io>
jamesc
force-pushed
the
elliott/service_account
branch
from
32d4bfe
to
a29866d
Compare
When running services under the operator that need a service
account it is impossible to specify one given the current service
definition. This is useful for services running in pods that need to communicate with the kubernetes API with RBAC mode enabled
Signed-off-by: Elliott Davis elliott@excellent.io