Contas de Serviço

Início
Usuários e grupos
Contas de serviços default
Gerenciando contas de serviço
Gerenciando credenciais de contas de serviço
Gerenciando secrets
Usando credenciais de contas de serviço dentro de um container
Usando credenciais de contas de serviço externamente

---

Início

Quando uma pessoa usa a linha de comando ou o console web, o token da API faz a autenticação com o OpenShift. Entretanto, quando as credenciais de um usuário comum não estão disponíveis, os componentes da API fazem chamadas independentemente. Por exemplo:

• Controladores de replicação fazem chamadas de API para criar ou deletar pods
• Aplicações dentro de containers podem fazer chamadas API para propósitos de descoberta
• Aplicações externas podem fazer chamadas API para propósitos de monitoramento ou integração.

Contas de serviços prove um facil controle de acessar a API sem compartilhar as credenciais de usuários.

Usuários e grupos

Cada conta de serviço tem um usuário associado que pode ter permissões diferentes, igual um usuário comum. O usuário é entregue pelo projeto e nome: system:serviceaccount:<project>:<name>

Por exemplo, para adicionar a permissão view para a conta de serviço robot no projeto top-secret:

$ oc policy add-role-to-user view system:serviceaccount:top-secret:robot

Cada conta de serviço é também membro de dois grupos:

• system:serviceaccounts, que inclui todas as contas de serviço do sistema
• system:serviceaccounts:<project>, que inclui todas as contas de serviço no projeto especificado

Por exemplo, para permitir que todas as contas de serviço em todos os projetos visualizem recursos no projeto top-secret:

$ oc policy add-role-to-group view system:serviceaccounts -n top-secret

Para permitir que todas as contas de serviço no projeto managers possam editar recursos no projeto top-secret:

$ oc policy add-role-to-group edit system:serviceaccounts:managers -n top-secret

Contas de serviços default

Três contas de serviços são criadas automaticamente em todo projeto:

• builder é usado por build pods. É usado a função system:image-builder, que permite enviar imagens para qualquer stream no projeto usando o registro interno do Docker.
• deployer é usado por deployment pods e é usado a função system:deployer, que permite visualizar e modificar controladores de replicação e pods no projeto.
• default é usado para rodar todos os pods a menos que especificado uma conta de serviço diferente.

Todas as contas de serviço em um projeto recebem a função system:image-puller, que permite baixar imagens de qualquer stream image no projeto usando o registro interno do Docker.

Gerenciando contas de serviço

Contas de serviços são objetos API que existem com cada projeto. Elas podem ser criadas ou deletadas como qualquer outro objeto API.

$ oc create serviceaccount robot serviceaccounts/robot

Gerenciando credenciais de contas de serviços

Assim que uma conta de serviço é criada, duas secrets são automaticamente adicionadas a ela:

• Um token API
• Credenciais para o registro interno do Docker

Podem ser vistas ao descrever uma conta de serviço:

$ oc describe serviceaccount robot
Name:               robot
Labels:             <none>
Image pull secrets: robot-dockercfg-624cx

Mountable secrets:  robot-token-uzkbh
                    robot-dockercfg-624cx

Tokens:             robot-token-8bhpp
                    robot-token-uzkbh

O sistema garante que a conta de serviço sempre tenha um token API e credenciais do registro interno do Docker.

O token API e as credenciais do registro interno do Docker que foram gerados não expiram, mas eles podem ser removidos ao deletar a secret. Quando uma secret é deletada, uma nova é automaticamente gerada para substituir.

Gerenciando secrets

Além de fornecer credenciais de API, a conta de serviço de um pod determina quais secrets o pod tem permissão de usar.

Pods utilizam secret em duas formas:

• image pull secrets, fornecendo credenciais usadas para baixar imagens para os containers do pod
• mountable secrets, inserindo os dados das secrets em arquivos dentro do container

Para permitir que uma secret seja usada como uma image pull secret por uma conta de serviço do pod, execute oc secrets add --for=pull serviceaccount/<serviceaccount-name> secret/<secret-name>

Para permitir que uma secret seja montada por uma conta de serviço do pod, execute oc secrets add --for=mount serviceaccount/<serviceaccount-name> secret/<secret-name>

Este exemplo cria e adiciona uma secret em uma conta de serviço:

$ oc secrets new secret-plans plan1.txt plan2.txt
secret/secret-plans

$ oc secrets new-dockercfg my-pull-secret \
    --docker-username=mastermind \
    --docker-password=12345 \
    --docker-email=mastermind@example.com
secret/my-pull-secret

$ oc secrets add serviceaccount/robot secret/secret-plans --for=mount

$ oc secrets add serviceaccount/robot secret/my-pull-secret --for=pull

$ oc describe serviceaccount robot
Name:               robot
Labels:             <none>
Image pull secrets: robot-dockercfg-624cx
                    my-pull-secret

Mountable secrets:  robot-token-uzkbh
                    robot-dockercfg-624cx
                    secret-plans

Tokens:             robot-token-8bhpp
                    robot-token-uzkbh

Usando credenciais de contas de serviço dentro de um container

Quando um pod é criado, é especificado uma conta de serviço(ou utiliza a conta de serviço default), e é permitido usar as credenciais daquela conta de serviço e suas secrets da API.

Um arquivo contendo uma token API para uma conta de serviço do pod é automaticamente montada em /var/run/secrets/kubernetes.io/serviceaccount/token

Este token pode ser usado para fazer chamadas na API assim como na conta de serviço do pod. Este exemplo chama users/~ API para conseguir informações sobre o usuário identificado pelo token:

$ TOKEN="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"

$ curl --cacert /var/run/secrets/kubernetes.io/serviceaccount/ca.crt \
    "https://openshift.default.svc.cluster.local/oapi/v1/users/~" \
    -H "Authorization: Bearer $TOKEN"

{
  "kind": "User",
  "apiVersion": "v1",
  "metadata": {
    "name": "system:serviceaccount:top-secret:robot",
    "selfLink": "/oapi/v1/users/system:serviceaccount:top-secret:robot",
    "creationTimestamp": null
  },
  "identities": null,
  "groups": [
    "system:serviceaccounts",
    "system:serviceaccounts:top-secret"
  ]
}

Usando credenciais de contas de serviço externamente

O mesmo token pode ser distribuído para aplicações externas que precisam autenticar na API.

Use o comando oc describe secret <secret-name> para visualizar o token da conta de serviço API:

$ oc describe secret robot-token-uzkbh -n top-secret
Name:   robot-token-uzkbh
Labels:   <none>
Annotations:  kubernetes.io/service-account.name=robot,kubernetes.io/service-account.uid=49f19e2e-16c6-11e5-afdc-3c970e4b7ffe

Type: kubernetes.io/service-account-token

Data
====
token:  eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...


$ oc login --token=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...
Logged into "https://server:8443" as "system:serviceaccount:top-secret:robot" using the token provided.

You don't have any projects. You can try to create a new project, by running

    $ oc new-project <projectname>

$ oc whoami
system:serviceaccount:top-secret:robot