Available images:
The Conjur authenticator client is designed to have a light footprint both in terms of storage and memory consumption. It has very few components:
sleep
binary from busybox for debuggingtar
binary from busybox to meet the requirement of the authentication serviceThe client is configured entirely through environment variables. These are listed below.
Are you using this project with Conjur Open Source? Then we strongly recommend choosing the version of this project to use from the latest Conjur OSS suite release. Conjur maintainers perform additional testing on the suite release versions to ensure compatibility. When possible, upgrade your Conjur version to match the latest suite release; when using integrations, choose the latest suite release that matches your Conjur version. For any questions, please contact us on Discourse.
MY_POD_NAME
: Pod name (see downwards API)MY_POD_NAMESPACE
: Pod namespace (see downwards API)CONTAINER_MODE
: Set this to init
to run as an init container that will exit after performing authentication. All other values (including blank) will cause the container to run as a sidecar.CONJUR_ACCOUNT
: Conjur account nameCONJUR_AUTHN_URL
: URL pointing to authenticator service endpointCONJUR_AUTHN_LOGIN
: Host login for pod e.g. namespace/service_account/some_service_account
CONJUR_SSL_CERTIFICATE
: Public SSL cert for Conjur connectionCONJUR_TOKEN_TIMEOUT
: Timeout for fetching a new token (defaults to 6 minutes).
In most cases, this variable should not be modified. The value should be in a
format that can be parsed with time.ParseDuration (e.g "6m0s")Flow:
The client's process logs its flow to stdout
and stderr
.
/run/conjur/access-token
)By default, the Conjur Kubernetes authenticator client container runs using
a default username authenticator
, user ID 777
, and group ID 777
.
If you would like to run the authenticator client on a non-OpenShift Kubernetes platform, using a non-default user and/or group ID in a Pod that includes the authenticator client as a sidecar or init container, then you can configure your Pod manifest as follows:
NOTE: This technique is not supported on OpenShift platforms. For OpenShift platforms, the authenticator container should be run with the container's default user and group.
Configure the
Pod's Security Context
for the desired user ID / group ID. Setting the fsGroup
to the desired
user group will cause Kubernetes to set that group as the owner of
any files that are created in volumes of type emptyDir
, including the
authenticator client's SSL certificate and the application's Conjur access
token.
For example, to run with a user ID of 65534
(the nobody
user) and a
group ID of 65534
(the nobody
group):
securityContext:
fsGroup: 65534
runAsGroup: 65534
runAsNonRoot: true
runAsUser: 65534
Include a volumeMount
for the authenticator client certificate directory:
volumeMounts:
- name: client-ssl
mountPath: /etc/conjur/ssl
Include an emptyDir
volume for the authenticator client certificate
directory. Using a volume of type emptyDir
allows the client certificate
file to be created with its group owner set to the value of fsGroup
as
configured in the above PodSecurityContext:
volumes:
- name: client-ssl
emptyDir:
medium: Memory
We welcome contributions of all kinds to this repository. For instructions on how to get started and descriptions of our development workflows, please see our contributing guide.
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo update
helm pull bitnami/postgresql --version <version to update to>
cp postgresql-<version>.tgz vendor_helm/.
Update bin/test-workflow/6_app_deploy_backend.sh
to reference the new file