Issue 1:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.): No

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): deployment

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG REPORT

Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.1", GitCommit:"33cf7b9acbb2cb7c9c72a10d6636321fb180b159", GitTreeState:"clean", BuildDate:"2016-10-10T18:19:49Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"windows/amd64"}
Server Version: version.Info{Major:"1", Minor:"4", GitVersion:"v1.4.5", GitCommit:"5a0a696437ad35c133c0c8493f7e9d22b0f9b81b", GitTreeState:"clean", BuildDate:"2016-10-29T01:32:42Z", GoVersion:"go1.6.3", Compiler:"gc", Platform:"linux/amd64"}

Environment:

Cloud provider or hardware configuration: Google Cloud

OS (e.g. from /etc/os-release): GCE Container VM

Kernel (e.g. uname -a): N/A

Install tools: N/A

Others: N/A

What happened:

We use kubectl replace -f deployment.json to update deployment resources in our cluster. We do this because we generate deployment.json, and pass it to either create or replace depending on whether or not the resource already exists

What you expected to happen:

We expected that replace will trigger the rollout logic, however kubectl rollout status deployment ... always seems to return immediately available, even when kubectl get pods shows pods creating / being terminated (in violation of the rolling update strategy as well).

How to reproduce it (as minimally and precisely as possible):

kubectl replace -f deployment.json where deployment.json describes a deployment resource. You can try changing the image version in a container in deployment.json and running the replace command.

Anything else do we need to know:

N/A

Issue 2:
Is this a request for help? (If yes, you should use our troubleshooting guide and community support channels, see http://kubernetes.io/docs/troubleshooting/.): No, filing after reproducing the issue in discussion on sig-auth with @ericchiang and @whitlockjc and figured out a workaround

What keywords did you search in Kubernetes issues before filing this one? (If you have found any duplicates, you should instead reply there.): kubernetes rbac policies

Is this a BUG REPORT or FEATURE REQUEST? (choose one): BUG

Kubernetes version (use kubectl version):

Client Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.0", GitCommit:"283137936a498aed572ee22af6774b6fb6e9fd94", GitTreeState:"clean", BuildDate:"2016-07-01T19:26:38Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"3", GitVersion:"v1.3.4+coreos.0", GitCommit:"be9bf3e842a90537e48361aded2872e389e902e7", GitTreeState:"clean", BuildDate:"2016-08-02T00:54:53Z", GoVersion:"go1.6.2", Compiler:"gc", Platform:"linux/amd64"}

Environment:

Cloud provider or hardware configuration: CoreOS Single node - https://coreos.com/kubernetes/docs/latest/kubernetes-on-vagrant-single.html

OS (e.g. from /etc/os-release):

localhost manifests # cat /etc/os-release
NAME=CoreOS
ID=coreos
VERSION=1122.0.0
VERSION_ID=1122.0.0
BUILD_ID=2016-07-27-0739
PRETTY_NAME="CoreOS 1122.0.0 (MoreOS)"
ANSI_COLOR="1;32"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues"

Kernel (e.g. uname -a):

localhost manifests # uname -a
Linux localhost 4.7.0-coreos #1 SMP Wed Jul 27 07:30:04 UTC 2016 x86_64 Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz GenuineIntel GNU/Linux

Install tools:

Others:

What happened:

After configuring both OIDC and RBAC on the api server and getting a JWT for the user named as the super user k8s refuses to authorize any api calls. In order to work around the issue, I had to configure an X509 client as the super user, at which point I was able to bootstrap the policies and my oidc user and user's groups were properly recognized by k8s.

What you expected to happen:

Since the user is a super-user, all commands should execute without checking the rbac authorization system. The x509 login should not have been necessary.

How to reproduce it (as minimally and precisely as possible):

Deploy k8s

Add the openid connect flags to the api server, here was my config with KeyCloak:

- --oidc-issuer-url=https://kcdev.tremolosecurity.com:8443/auth/realms/kubernetes
- --oidc-client-id=kubernetes
- --oidc-username-claim=preferred_username
- --oidc-groups-claim=user_role
- --oidc-ca-file=/etc/kubernetes/ssl/kc-ca.pem

Verify login with OAuth2 bearer token succeeds

Add RBAC Authorization parameters:

- --runtime-config=extensions/v1beta1/networkpolicies=true,rbac.authorization.k8s.io/v1alpha1
- --oidc-issuer-url=https://kcdev.tremolosecurity.com:8443/auth/realms/kubernetes
- --oidc-client-id=kubernetes
- --oidc-username-claim=preferred_username
- --oidc-groups-claim=user_role
- --oidc-ca-file=/etc/kubernetes/ssl/kc-ca.pem
- --authorization-rbac-super-user=mmosley.ent2k12.domain.com
- --authorization-mode=RBAC

and here is an example JWT:

{
"jti": "34d2d176-1f33-4522-ac75-c1f1e2ba291d",
"exp": 1472061895,
"nbf": 0,
"iat": 1472061595,
"iss": "https://kcdev.tremolosecurity.com:8443/auth/realms/kubernetes",
"aud": "kubernetes",
"sub": "cc28e060-4c63-4380-94a7-63e2aad1f372",
"typ": "Bearer",
"azp": "kubernetes",
"auth_time": 1472061358,
"session_state": "8b3773bc-23ca-4f75-8c35-d2bf197d4057",
"acr": "0",
"client_session": "85550ebd-fe8c-4212-bf37-3579b3532f76",
"allowed-origins": [],
"realm_access": {
"roles": [
"uma_authorization"
]
},
"resource_access": {
"account": {
"roles": [
"manage-account",
"view-profile"
]
}
},
"user_role": [
"admin"
],
"name": "mmosley@ent2k12.domain.com Mosley",
"preferred_username": "mmosley.ent2k12.domain.com",
"given_name": "mmosley@ent2k12.domain.com",
"family_name": "Mosley",
"email": "matt.mosley@tremolosecurity-test.com"
}

Try to use kubectl, all requests results in a 403 (unauthorized)

Change the api server to use a ca client certificate

- --runtime-config=extensions/v1beta1/networkpolicies=true,rbac.authorization.k8s.io/v1alpha1
- --oidc-issuer-url=https://kcdev.tremolosecurity.com:8443/auth/realms/kubernetes
- --oidc-client-id=kubernetes
- --oidc-username-claim=preferred_username
- --oidc-groups-claim=user_role
- --oidc-ca-file=/etc/kubernetes/ssl/kc-ca.pem
- --authorization-rbac-super-user=kube-admin
- --authorization-mode=RBAC

Try using kubectl with the client certificate

Anything else do we need to know:

OpenID Connect provider is KeyCloak 2.1